PDF de programación - La Catedral y El Bazar

La Catedral y
El Bazar.
Por Eric S. Raymond


11 de Septiembre 3009 | 10ºA
(B7600HFI) Mar del Plata
Buenos Aires | Argentina


T +54 223 495.1785
W openbiz.com.ar
E [email protected]







OPENBIZ | La Catedral y el Bazar | Pág. 1



Tabla de Contenidos

Tabla de Contenidos ................................................................................... 1
Nota del Autor: .......................................................................................... 3
1. La catedral y el bazar ............................................................................... 5
2. El correo debe pasar................................................................................. 7
3. La importancia de tener usuarios............................................................... 11
4. Libere pronto, Libere a menudo................................................................ 13
5. ¿Cuando una rosa deja de serlo? ............................................................... 17
6. Popclient se convierte en Fetchmail ........................................................... 19
7. Fetchmail se hace mayor ......................................................................... 23
8. Algunas lecciones más a partir de 'fetchmail'................................................ 25
9. Condiciones previas necesarias para el modelo bazar ..................................... 27
10. El contexto social del software abierto ...................................................... 29
11. Agradecimientos ................................................................................. 33
12. Lecturas adicionales.............................................................................. 33
13. Historial de versiones y cambios:.............................................................. 35
Notas de Traducción e Información de Copyright:.......................................... 36



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 2

Esta página fue dejada en blanco de manera intencional.-



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 3

Nota del Autor:


Analizo un proyecto de software de dominio público desarrollado con éxito,
fetchmail, que se realizó como una prueba deliberada de algunas teorías
sorprendentes sobre ingeniería de software sugeridas por la historia de Linux.


Presento estas teorías en términos de dos estilos de desarrollo
completamente distintos, el modelo “catedral'', aplicable a la mayor parte de los
desarrollos realizados en el mundo del software comercial, frente al modelo
“bazar'', más propio del mundo Linux.


Muestro que estos modelos se derivan de puntos de partida opuestos

sobre la naturaleza del proceso de depuración del software.


Prosigo manteniendo a partir de la experiencia Linux la hipótesis de que
“Dado un número suficiente de ojos, todos los errores son irrelevantes'',
sugiriendo analogías productivas con otros sistemas auto-correctores integrados
por agentes autónomos, y concluyo realizando alguna exploración de las
consecuencias de este punto de vista sobre el futuro del software.



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 4

Esta página fue dejada en blanco de manera intencional.-



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 5

1. La catedral y el bazar

Linux es subversivo. ¿Quién hubiera pensado, tan solo cinco años atrás,
que un sistema operativo de gran calidad pudiera concretarse como por ensalmo
a partir del trabajo aficionado y a tiempo parcial de varios miles de
programadores esparcidos por todo el planeta y conectados tan solo por las
tenues hebras de Internet?.


Desde luego, yo no. En el momento en que Linux surgió en la pantalla de
mi radar a principio de 1993, había estado ya involucrado en el desarrollo de Unix
y de software abierto durante diez años. Era uno de los que primero contribuyó al
desarrollo de GNU a mediados de los ochenta. Había lanzado en la red una
cantidad respetable de software abierto, desarrollando o co-desarrollando varios
programas (nethack, los modos VC y GUD de Emacs, xlife y algunos más) que
aún se emplean ampliamente hoy en día. Creía saber como se hacía.


Linux puso patas arriba mucho de lo que yo creía que sabía. Había estado
predicando durante años el evangelio Unix consistente en herramientas pequeñas,
rápido desarrollo de prototipos y programación evolutiva. Pero también creía que
existía una cierta complejidad crítica por encima de la cual era preciso recurrir a
un enfoque más centralizado y planificado desde el principio. Creía que el
software más importante (los sistemas operativos o las herramientas realmente
grandes tales como Emacs) necesitaban ser construidas al modo de las
catedrales, ser cuidadosamente ensamblados por magos o pequeñas bandas de
hechiceros trabajando en un espléndido aislamiento, sin que hubiera lugar al
lanzamiento de versiones de prueba antes de que hubiera llegado el momento.


El estilo de desarrollo de Linus Torvalds - lanzar versiones de prueba
enseguida y a menudo, delegar cuanto sea posible, estar abierto hasta el punto
de resultar promiscuo - resultó una verdadera sorpresa. Nada que ver con la
silenciosa y reverente construcción de una catedral -- la comunidad Linux, por
contra, parecía semejarse a un gran bazar bullicioso con diferentes agendas y
enfoques (adecuadamente reflejado por los depósitos de software Linux, que
admitían contribuciones de cualquiera) del cual solo parecía posible que
emergiera un sistema coherente y estable mediante una sucesión de milagros.


El hecho de que este estilo bazar parecía funcionar, y bien, me produjo
una auténtica conmoción. Mientras lo iba aprendiendo trabajé, además de en
proyectos individuales, para intentar comprender porqué el mundo Linux no solo
no se desmoronaba en medio de una colosal confusión sino que parecía ir de
logro en logro a una velocidad difícil de imaginar para los constructores de
catedrales.


A mediados de 1996 creí que lo comenzaba a entender. La casualidad me
proporcionó una forma perfecta de poner a prueba mí teoría, mediante un
proyecto de software abierto que podía intentar conducir de forma deliberada
según el estilo bazar. Lo hice así - y resultó un éxito incuestionable.



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 6

En el resto de este artículo, contaré la historia de ese proyecto, y lo
emplearé para proponer algunas reglas sobre desarrollo eficaz de software
abierto. No todas son cosas que aprendí en el mundo Linux, pero veremos que
este les aporta un brillo especial. Si estoy en lo cierto, le permitirán entender
exactamente qué es lo que hace de la comunidad Linux una fuente tal de buen
software - y le ayudarán a Ud. a ser más productivo.



W openbiz.com.ar
E [email protected]



OPENBIZ | La Catedral y el Bazar | Pág. 7

2. El correo debe pasar

Desde 1993, he estado manteniendo la parte técnica de un pequeño
proveedor de Internet de acceso libre llamado Chester County InterLink (CCIL) en
West Chester, Pennsylvania (soy cofundador de CCIL y escribí nuestro único
sofware BBS multiusuario -- como puedes comprobar realizando un "telnet" a
locke.ccil.org. En la actualidad da soporte a casi tres mil usuarios a través de
diecinueve líneas.) Este trabajo me permitía tener un acceso a la red durante 24
horas diarias a través de la línea de 56K del CCIL -- de hecho, ¡casi fui yo el que
exigió tal cosa!.


En consecuencia, me he acostumbrado bastante a tener un acceso
instantáneo al email en Internet. Por una serie de complejas razones, era difícil
conseguir que SLIP funcionara entre la máquina de mi casa (snark.thyrsus.com) y
CCIL. Cuando finalmente lo conseguí, me encontré teniendo que realizar
periódicamente sesiones de "telnet" en "locke" para poder comprobar mi correo,
lo que me resultó molesto. Lo que yo quería era que mi correo llegara a "snark",
de modo que biff(1) pudiera informarme de su llegada.


Una simple redirección mediante el "sendmail forwarding" no hubiera
funcionado, ya que "snark" no está siempre en red y carece de dirección IP
estática. Lo que yo necesitaba era un programa que pudiera recogerlo a través de
mi conexión SLIP y se trajera mi correo para entregarlo en mi casa. Sabía que
tales cosas existían, y que la mayor parte de ellas empleaban un sencillo
protocolo denominado POP (Post Office Protocol). Y estaba bastante seguro de
que el sistema operativo BSD/OS con que funcionaba "locke" contaba ya con un
servidor POP3.


Necesitaba un cliente POP3. Por lo tanto me di unas vueltas por la red y
encontré uno. De hecho, encontré tres o cuatro. Empleé pop-perl durante una
temporada, pero echaba en falta lo que parecía ser una capacidad obvia, la
habilidad de capturar las direcciones del correo recogido de modo que las
contestaciones funcionaran correctamente.


El problema era éste: supongamos que alguien llamado `joe' en "locke"
me envía un mensaje. Si lo recojo y lo