PDF de programación - La Catedral y el Bazar

LA CATEDRAL Y EL BAZAR
POR ERIC S. RAYMOND

Fecha: 1998/01/29 05:47:17

Analizo un proyecto de software de dominio público desarrollado con éxito, fetchmail, que se reali-
zó como una prueba deliberada de algunas teorías sorprendentes sobre ingeniería de software sugeri-
das por la historia de Linux. Presento estas teorías en términos de dos estilos de desarrollo completa-
mente 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 es-
tos 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 explora-
ción de las consecuencias de este punto de vista sobre el futuro del software.

1. NOTA DEL TRADUCTOR AL CASTELLANO:
El término "Free Software" se ha traducido como "software abierto". Se ha preferido esta deno-

minación a la de "software de dominio público" (que correspondería estrictamente al término "public
domain software") para enfatizar lo que se cree es una característica necesaria de este tipo de soft-
ware: disponer del código fuente del programa. El término "hacker" resulta de difícil traducción. En
ocasiones se ha traducido como "programador aficionado", si bien ha sido más frecuente que se
haya dejado sin traducir. Según el libro "Léeme.ya", ISBN 84-605-7033-9, pg. 734, la definición de
"hacker" vendría a ser la siguiente:

"Hacker: Citando literalmente el libro 'Linux. Edición especial', pg. 30: '... la definición popular de
hacker tiene una connotación negativa en la sociedad actual... la actividad de los hackers tiene
que ver básicamente con el aprendizaje de todo lo que hay que conocer de un sistema, la posibili-
dad de sumergirse en éste al grado de abstraerse, y la capacidad de repararlo cuando se cae. En
general a los hackers les interesa conocer el funcionamiento de los sistemas que encuentran inte-
resantes. ...algunos hackers transponen esa línea y se convierten en lo que la comunidad hacker
ha denominado cracker. A los hackers de la computación les molesta bastante que los comparen
con estos vándalos y delincuentes que los medios de difusión popular llaman equivocadamente
hackers en vez de crackers...' .

Pues eso, no se confunda. A pesar de todo, un colega bastante enterado mantiene que esa sería
la definición de "wizard" (brujo o mago) y no la de "hacker", siempre con alguna connotación en el lí-
mite de la legalidad. Lo dejo a su elección.'

Edición: 09 de mayo de 2007

Elaborado con OpenOffice

Página 1 de 17

1. LA CATEDRAL Y EL BAZAR

Linux es subversivo. ¿Quién hubiera pensado, tan solo cinco años atrás, que un sistema opera-

tivo 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 va-
rios 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 pro-
gramació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 hu-
biera 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 verda-
dera sorpresa. Nada que ver con la silenciosa y reverente construcción de una catedral -- la comuni-
dad Linux, por contra, parecía semejarse a un gran bazar bullicioso con diferentes agendas y enfo-
ques (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 conmo-

ción. Mientras lo iba aprendiendo trabajé, además de en proyectos individuales, para intentar com-
prender 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 cate-
drales.

A mediados de 1996 creí que lo comenzaba a entender. La casualidad me proporcionó una for-

ma perfecta de poner a prueba mi teoría, mediante un proyecto de software abierto que podía inten-
tar conducir de forma deliberada según el estilo bazar. Lo hice así -- y resultó un éxito incuestiona-
ble.

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

Edición: 09 de mayo de 2007

Elaborado con OpenOffice

Página 2 de 17

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 cofunda-
dor de CCIL y escribí nuestro único sofware BBS multiusuario -- como puedes comprobar realizan-
do un "telnet" a locke.ccil.org. En la actualidad da soporte a casi tres mil usuarios a través de die-
cinueve 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 In-

ternet. Por una serie de complejas razones, era difícil conseguir que SLIP funcionara entre la máqui-
na 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) pudie-
ra informarme de su llegada.

Una simple redirección mediante el "sendmail forwarding" no hubiera funcionado, ya que

"snark" no está siempre en red y cerece de dirección IP estática. Lo que yo necesitaba era un progra-
ma 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 dí unas vueltas por la red y encontré uno. De he-
cho, 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 envío a "snark" e intento contestar, mi programa de correo intentará enviarlo alegre-
mente a un inexistente 'joe' en "snark". Editar a mano las direcciones de las respuestas para restau-
rar el original '@ccil.org' se convirtió pronto en una considerable molestia.

Era claramente algo que el ordenador debía hacer en mi lugar. (De hecho, según RFC1123 sec-

ción 5.2.18, sendmail debería estar haciéndolo.) ¡Pero ninguno de los clientes POP sabía como!. Y
esto nos lleva a la primera lección:

I.

TODOS LOS TRABAJOS BUENOS EN SOFTWARE COMIENZAN TRATANDO DE PALIAR UN PROBLEMA PERSONAL DEL QUE
LOS PROGRAMA.

Quizá esto hubiera debido resultar evidente (se sabe desde hace tiempo que "La necesidad es la
madre de la invención") pero los programadores desperdician demasiado a menudo sus días pelean-
do por dinero con programas que no necesitan y a los que no aman. No así en el mundo Linux -- lo
que puede explicar porqué la calidad media del software desarrollado por dicha comunidad es tan
alta.

¿Me entregué de inmediato, por tanto, a un frenético intento de programación de un nuevo

cliente POP3 para competir con los que ya había?. Jamás de los jamases. Busqué cuidadosamente
entre las utilidades POP que tenía a mano preguntándome "¿cual es la que más se acerca a lo que
yo quiero?". Porque ...

II. LOS BUENOS PROGRAMADORES SABEN QUÉ ESCRIBIR. LOS GRANDES SABEN QUÉ REESCRIBIR (Y REUTILIZAR).
Aunque no pretendo ser un gran programador, trato de imitarlos. Una carac