´Indice general

18
CAPÍTULO 2. CALIDAD, REUSO Y MODELOS
tarea de debugging) lo cual conduce a la innovación y al avance rápido en
el desarrollo y la evolución de los productos de software.
Aún cuando no existe ningún artículo donde se describa formalmente el
modelo de OSS (Open Source Software), Raymond[25] describe a la comunidad
open source y sus métodos de desarrollo de software. El título del libro
(The Cathedral and The Bazaar) es una metáfora: la producción propietaria
(o de patente) de software como la construcción cuidadosamente planeada
de una catedral, y la producción del software open source como las interacciones
caóticas de los participantes en un bazar del medio oriente 5 . Y
aunque esta analogía parecería quizá extrema, apunta a la diferencia principal
entre los dos tipos de creación de software: sofisticada administración
central contra desarrolladores y usuarios débilmente acoplados en miles de
proyectos independientes.
Más allá de las connotaciones que pudieran tener los conceptos de centralización
y descentralización, habría que decir que administración central
no necesariamente implica eficiencia, ni la descentralización ineficiencia. De
hecho, Raymond confiesa que él mismo no estaba convencido de la eficiencia
o efectividad del modelo del bazar. Para convencerse lo puso a prueba
iniciando el desarrollo de un proyecto que llamó Fetchmail (inicialmente
Pop-Client) bajo los principios de desarrollo de Linus Torvald tratando de
entender por qué el mundo Linux no se había desintegrado en la confusión
sino que parecía reforzarse continuamente a una velocidad difícilmente imaginable
para los constructores de catedrales. El proyecto Fetchmail tuvo un
éxito significante.
Según Raymond[25], los modelos de la catedral y del bazar se basan
en dos estilos de desarrollo fundamentalmente diferentes y se derivan de
suposiciones opuestas acerca de la naturaleza de la depuración (debugging).
Raymond propone algunos aforismos que describen el modelo open source
de desarrollo. Enseguida se presentan algunos de ellos:
Release Early, Release Often. And listen to your costumers. (Liberar
pronto, liberar con frecuencia). Y escucha a tus usuarios.
Ley de Linus: Given enough eyeballs, all bugs are shallow (Dada una
base suficientemente grande de beta-testers y co-desarrolladores, casi
cada problema será caracterizado rápidamente y su solución será obvia
para alguien.)
Los buenos programadores saben qué escribir y los grandes saben
5 bazar = mercado en persa