La Catedral y El Bazar

INFORMATICA, SECCION ID1A
ALUMNO: HECTOR VASQUEZ

C.I 31.665.531
ACTIVIDAD: LECTURA
La catedral y el bazar:
Cuando Linux apareció en mi camino, a principios de 1993,
yo tenía invertidos en UNIX y el desarrollo del software libre
alrededor de diez años. Fui uno de los primeros en
contribuir con GNU a mediados de los 80 y he estado
aportando una buena cantidad de software libre a la red,
desarrollando o colaborando en varios programas que
todavía son ampliamente usados. Creí que sabía cómo
debían hacerse las cosas.
Linux vino a trastocar buena parte de lo que pensaba que
sabía. Había estado predicando durante años el evangelio
UNIX de las herramientas pequeñas, de la creación rápida
de prototipos y de la programación evolutiva. Pero también
creía que existía una determinada complejidad crítica, por
encima de la cual se requería un enfoque más planeado y
centralizado. Yo pensaba que el software de mayor
envergadura requería construirse como las catedrales, es
decir, que debía ser cuidadosamente elaborado por genios
o pequeñas bandas de magos trabajando encerrados a
piedra y lodo, sin liberar versiones beta antes de tiempo.
El estilo de desarrollo de Linus Torvalds me cayó de
sorpresa. No se trataba de ninguna forma reverente de
construir la catedral. Al contrario, la comunidad Linux se
asemejaba más a un bullicioso bazar de Babel, colmado de
individuos con propósitos y enfoques dispares , de donde
surgiría un sistema estable y coherente únicamente a partir
de una serie de artilugios.
El hecho de que este estilo de bazar parecía funcionar, y
funcionar bien, realmente me dejó sorprendido. A medida
que iba aprendiendo a moverme en ese medio, no sólo
trabajé arduamente en proyectos individuales, sino en
tratar de comprender por qué el mundo Linux no
naufragaba en el mar de la confusión, sino que se fortalecía
con una rapidez inimaginable para los constructores de
catedrales.
Creí empezar a comprender a mediados de 1996. El destino
me dio un medio perfecto para demostrar mi teoría, en la
forma de un proyecto de software libre que trataría de
realizar siguiendo el estilo del bazar de manera consciente.
Así lo hice y resultó un éxito digno de consideración.
En el resto de este artículo relataré la historia de este
proyecto, y la usaré para proponer algunos aforismos sobre
el desarrollo real del software libre. No todas estas cosas
fueron aprendidas del mundo Linux, pero veremos cómo
fue que les vino otorgar un sentido particular. Si estoy en lo
cierto, le servirán para comprender mejor qué es lo que
hace a la comunidad linuxera tan buena fuente de software;
y le ayudarán a ser más productivo.
County InterLink , en West Chester, Pennsylvania .
Desde 1993 he estado encargado de la parte técnica de un

pequeño ISP de acceso gratuito llamado Chester
Para ese entonces ya me había habituado al correo

electrónico. Por diversas razones fue difícil obtener SLIP
para enlazar mi máquina en casa y CCIL. Cuando finalmente
pude lograrlo, encontré que era particularmente molesto
tener que entrar por telnet a locke cada rato para revisar mi
correo. Lo que quería era que fuera reenviado a snark para
que biff me notificase cuando llegara.
Un simple redireccionamiento con sendmail no iba a
funcionar debido a que snark no siempre está en línea y no
tiene una dirección IP estática. Lo que necesitaba era un
programa que saliera por mi conexión SLIP y trajera el
correo hasta mi máquina. Yo sabía que tales programas ya
existían, y que la mayoría usaba un protocolo simple
llamado POP , de tal manera que me cercioré de que el
servidor POP3 estuviera en el sistema operativo BSD/OS de
locke.
Necesitaba un cliente POP3; de tal manera que lo busqué en
la red y encontré uno. En realidad hallé tres o cuatro. Usé
pop-perl durante un tiempo, pero le faltaba una
característica a todas luces evidente: la capacidad de
identificar las direcciones de los correos recuperados para
que las respuestas pudieran darse correctamente.
El problema era este: supongamos que un tal monty en
locke me envía un correo. Si yo lo bajaba desde snark y
luego intentaba responder, entonces mi programa de
correos dirigía la respuesta a un monty inexistente en snark.
La edición manual de las direcciones de respuesta para
pegarles el «@ccil.org», muy pronto se volvió algo muy
molesto.
Era evidente que la computadora tenía que hacer esto por
mí.
Todo buen trabajo de software comienza a partir de las

necesidades personales del programado
Esto podría sonar muy obvio: el viejo proverbio dice que «la
necesidad es la madre de todos los inventos».
Empero, hay muchos programadores de software que
gastan sus días, a cambio de un salario, en programas que ni
necesitan ni quieren. No ocurre lo mismo en el mundo
Linux; lo que sirve para explicar por qué se da una calidad
promedio de software tan alta en esa comunidad.
Por todo esto, ¿pensaran que me lancé inmediatamente a la
vorágine de escribir, a partir de cero, el programa de un
nuevo cliente POP3 que compitiese con los existentes?
¡Nunca en la vida! Revisé cuidadosamente las herramientas
POP que tenía al alcance, preguntándome «¿cuál se
aproxima más a lo que yo necesito?», porque...
Los buenos programadores saben qué escribir.
Aunque no presumo ser un extraordinario programador, he
tratado siempre de imitar a uno de ellos. Una importante
característica de los grandes programadores es la
meticulosidad con la que construyen. Saben que les
pondrán diez no por el esfuerzo sino por los resultados; y
que casi siempre será más fácil partir de una buena solución
parcial que de cero.
Linus, por ejemplo, no intentó escribir Linux partiendo de
cero. En vez de eso, comenzó por reutilizar el código y las
ideas de Minix, un pequeño sistema operativo tipo UNIX
hecho para máquinas 386.
Eventualmente terminó desechando o reescribiendo todo el
código del Minix, pero mientras contó con él le sirvió como
una importante plataforma de lanzamiento del proyecto en
gestación que posteriormente se convertiría en Linux.
Con ese espíritu, comencé a buscar una herramienta POP
que estuviese razonablemente escrita para ser usada como
plataforma inicial para mi desarrollo.
La tradición del mundo UNIX de compartir las fuentes
siempre se ha prestado a la reutilización del código.
posee terabytes de código fuente que están generalmente
disponibles. Así que es más probable que la búsqueda de
algo bueno tenga mayores probabilidades de éxito en el
mundo Linux que en ningún otro lado.
Así sucedió en mi caso. Además de los que había
encontrado antes, en mi segunda búsqueda conseguí un
total de nueve candidatos: fetchpop, PopTart, get-mail,
gwpop, pimp, pop-perl, popc, popmail y upop. El primero
que elegí fue el «fetchpop», un programa de Seung-Hong
Oh. Le agregué mi código para que tuviera la capacidad de
reescribir los encabezados y varias mejoras más, las cuales
fueron incorporadas por el propio autor en la versión 1.9.
Sin embargo, unas semanas después me topé con el código
fuente de «popclient», escrito por Carl Harris, y descubrí
que tenía un problema. Pese a que fetchpop poseía algunas
ideas originales , sólo podía manejar POP3, y estaba escrito
a la manera de un aficionado . El código de Carl era mejor,
bastante profesional y robusto, pero su programa carecía de
varias de las características importantes del fetchpop que
eran difíciles de implementar .
¿Seguía o cambiaba? Cambiar significaba desechar el código
que había añadido a cambio de una mejor base de
desarrollo.
Un motivo práctico para cambiar fue la necesidad de contar
con soporte de múltiples protocolos. POP3 es el protocolo
de servidor de correos que más se utiliza, pero no es el
único. Fetchpop y otros no manejaban
POP2, RPOP ó APOP, y yo tenía ya la idea vaga de añadir
IMAP sólo por entretenimiento.
«Contemple la posibilidad de desecharlo, de todos modos
tendrá que hacerlo.
Diciéndolo de otro modo: no se entiende cabalmente un

problema hasta que se implementa la primera solución. La
siguiente vez quizás uno ya sepa lo suficiente para
solucionarlo. Así que si quieres resolverlo, disponte a
empezar de nuevo al menos una vez.
Bien, me dije, los cambios a fetchpop fueron un primer
intento, así que cambio.
Después de enviarle mi primera serie de mejoras a Carl
Harris, el 25 de junio de 1996, me enteré de que él había
perdido el interés por popclient desde hacía rato. El
programa estaba un poco abandonado, polvoriento y con
algunas pulgas menores colgando. Como se le tenían que
hacer varias correcciones, pronto acordamos que lo más
lógico era que yo asumiera el control del proyecto.
Sin darme cuenta, el proyecto había alcanzado otras
dimensiones. Ya no estaba intentando hacerle unos cuantos
cambios menores a un cliente POP, sino que me había
hecho responsable de uno; y las ideas que bullían en mi
cabeza me conducirían probablemente a cambios mayores.
En una cultura del software que estimula el compartir el
código fuente, esta era la forma natural de que el proyecto
evolucionara.
Si tienes la actitud adecuada, encontrarás problemas
interesantes.
Pero la actitud de Carl Harris fue aún más importante.
Cuando se pierde el interés en un programa, el último deber

es cederlo a un sucesor competente
Sin siquiera discutirlo, Carl y yo sabíamos que el objetivo

común era obtener la mejor solución. La única duda entre
nosotros era si yo podía probar que el proyecto iba a
quedar en buenas manos. Una vez que lo hice, él actuó de
buena gana y con diligencia. Espero comportarme igual
cuando llegue mi turno.
La importancia de contar con usuarios
Así fue como heredé popclient. Además, recibí su base de

usuarios, lo cual fue tanto o más importante. Tener usuarios
es maravilloso. No sólo porque prueban que uno está
satisfaciendo una necesidad, que ha hecho algo bien, sino
porque, cultivados adecuadamente, pueden convertirse en
magníficos asistentes.
Otro aspecto importante de la tradición UNIX, que Linux, de
nuevo, lleva al límite, es que muchos de los usuarios son
también hackers, y, al estar disponible el código fuente, se
vuelven hackers muy efectivos. Esto puede resultar
tremendamente útil para reducir el tiempo de depuración
de los programas. Con un buen estímulo, los usuarios
diagnosticarán problemas, sugerirán correcciones y
ayudarán a mejor los programas mucho más rápido de lo
que uno lo haría sin ayuda.
Tratar a los usuarios como colaboradores es la forma más
apropiada de mejorar el código, y la más efectiva de
depurarlo.
Suele ser fácil subestimar el poder de este efecto. De hecho,
es posible que todos continuásemos desestimando la
capacidad multiplicadora que adquiriría con el número de
usuarios y en contra de la complejidad de los sistemas,
hasta que así nos lo vino a demostrar Linus.
En realidad, considero que la genialidad de Linus no radica
en la construcción misma del kernel de Linux, sino en la
invención del modelo de desarrollo de Linux. Cuando en una
ocasión expresé esta opinión delante de él, sonrió y repitió
en voz baja una frase que ha dicho muchas veces:
«Básicamente, soy una persona muy floja que le gusta
obtener el crédito por lo que, realmente, hacen los demás».
Flojo como una broma. O, como diría Robert Heinlein,
demasiado flojo para fallar.
En retrospectiva, un precedente de los métodos y el éxito
que tiene Linux podría encontrarse en el desarrollo de las
bibliotecas del Emacs GNU, así como los archivos del código
de Lisp. En contraste con el estilo de construcción catedral
del núcleo del Emacs escrito en C, y de muchas otras
herramientas de la FSF, la evolución del código de Lisp fue
bastante fluida y, en general, dirigida por los propios
usuarios. Las ideas y los prototipos de los modos se
describían tres o cuatro veces antes de alcanzar su forma
estable final.
Mientras que las frecuentes colaboraciones informales se
hacían posibles gracias a la internet, al estilo Linux.
Emacs, una colaboración tipo Linux, que realicé por correo

electrónico conjuntamente con otras tres personas, de las
cuales solamente he conocido a una hasta la fecha. VC era
un front-end para SCCS, RCS y posteriormente CVS, que
ofrecía controles de tipo «al toque» para operaciones de
control de versiones desde Emacs. Era el desarrollo de un
pequeño y, hasta cierto punto, rudimentario modo sccs que
alguien había escrito. El desarrollo de VC tuvo éxito porque,
a diferencia del Emacs mismo, el código de
Emacs en Lisp podía pasar por el ciclo de publicar, probar y
depurar, muy rápidamente.
Libere rápido y a menudo
Las publicaciones rápidas y frecuentes del código

constituyen una parte crítica del modelo Linux de
desarrollo. La mayoría de los programadores, entre los que
me incluyo, creía antes que era una mala política
involucrarse en proyectos más grandes triviales, debido a
que las primeras versiones, casi por definición, salen
plagadas de errores, y a nadie le gusta agotar la paciencia
de los usuarios.
Esta idea reafirmaba la preferencia de los programadores
por el estilo catedral de desarrollo. Si el objetivo principal
era que los usuarios vieran la menor cantidad de errores,
entonces sólo había que liberar una vez cada seis meses y
trabajar como burro en la depuración en el ínterin de las
versiones que se saquen a la luz. El núcleo del Emacs escrito
en C se desarrolló de esta forma. No así la biblioteca de Lisp,
ya que los repositorios de los archivos de Lisp, donde se
podían conseguir versiones nuevas y en desarrollo del
código, independientemente del ciclo de desarrollo del
Emacs, estaban fuera del control de la FSF.
El más importante de estos archivos fue el elisp de la
Universidad Estatal de Ohio, el cual se anticipó al espíritu y a
muchas de las características de los grandes archivos
actuales de Linux.
.

La Catedral y El Bazar

Cargado por

Copyright:

Formatos disponibles

La Catedral y El Bazar

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

La Catedral y El Bazar

Cargado por

Copyright:

Formatos disponibles

INFORMATICA, SECCION ID1A

ALUMNO: HECTOR VASQUEZ

Desde 1993 he estado encargado de la parte técnica de un

Para ese entonces ya me había habituado al correo

Todo buen trabajo de software comienza a partir de las

Diciéndolo de otro modo: no se entiende cabalmente un

Cuando se pierde el interés en un programa, el último deber

Sin siquiera discutirlo, Carl y yo sabíamos que el objetivo

Así fue como heredé popclient. Además, recibí su base de

Emacs, una colaboración tipo Linux, que realicé por correo

Libere rápido y a menudo

Las publicaciones rápidas y frecuentes del código

También podría gustarte