dingofanmadrid

1 La Catedral y el Bazar

Linux es subversivo. ¿Quién hubiera pensado hace apenas cinco años que un sistema operativo de talla mundial surgiría, como por arte de magia, gracias a la actividad hacker desplegada en ratos libres por varios miles de programadores diseminados en todo el planeta, conectados solamente por los tenues hilos de la Internet?

Lo que si es seguro es que yo no. Cuando Linux apareció en mi camino, a principios de 1993, yo tenía invertidos en UNIX y el desarrollo de software libre alrededor de diez años. Fui uno de los primeros en contribuir con GNU a mediados de los ochentas y he estado aportando una buena cantidad de software libre a la red, desarrollando o colaborando en varios programas (NetHack, los modos VC y GUD de Emacs, xlife y otros) 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 (sistemas operativos y herramientas realmente grandes, tales como Emacs) 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 ("libere rápido y a menudo, delegue todo lo que pueda, sea abierto hasta el punto de la promiscuidad") 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 (fielmente representados por los repositorios de archivos de Linux, que pueden aceptar aportaciones de quien sea), 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 como 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.
2 El correo tenía que llegar

Desde 1993 he estado encargado de la parte técnica de un pequeño ISP de acceso gratuito llamado Chester County InterLink (CCIL), en West Chester, Pennsylvania (fui uno de los fundadores de CCIL y escribí su original software BBS multiusuario, el cual puede verse entrando a telnet://locke.ccil.org . Actualmente soporta más de tres mil usuarios en 19 líneas). Este empleo me permitió tener acceso a la red las 24 horas del día a través de la línea de 56K de CCIL, ¡de hecho, prácticamente él me lo demandaba!.

Para ese entonces ya me habí habituado al correo electrónico. Por diversas razones fue difícil obtener SLIP para enlazar mi máquina en casa (snark.thyrsus.com) 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(1) 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 (Post Office Protocol, Protocolo de Oficina de Correos), de tal manera que me cercioré 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 envia un correo. Si yo lo jalaba 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í. (De hecho, de acuerdo con RFC1123, sección 5.2.18, sendmail debería de estarlo haciendo.) ¡Sin embargo, ninguno de los clientes POP lo hacía realmente! Esto nos lleva a la primera lección:

1. 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)

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

2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).

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 (OS) 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 (ésta es la razón por la que el proyecto GNU escogió a UNIX como su OS base, pese a las serias reservas que se tenían). El mundo Linux ha asumido esta tradición hasta llevarla muy cerca de su límite tecnológico; posee terabytes de código fuente que estámn 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ú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 agregue mi código par 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 (tal como su modo demonio), sólo podía manejar POP3, y estaba escrito a la manera de un aficionado (Seung-Hong era un brillante programador, pero no tenía experiencia, y ambas características eran palpables). 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 (incluyendo las que yo mismo había agregado).

¿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 (Protocolo de Acceso a Mensajes por Internet, el protocolo de correos más poderoso y reciente) sólo por entretenimiento.

Pero había una razón más teórica para pensar que el cambio podía ser una buena idea, algo que aprendí mucho antes de Linux:

3. "Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11)

Diciéndolo de otro modo: no se entiende cabalmente un problema hasta que se implementa la primera solución. La siguiente vez quizáas 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 entere 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, ésta era la forma natural de que el proyecto evolucionara. Yo actuaba de acuerdo con lo siguiente:

4. Si tienes la actitud adecuada, encontrarás problemas interesantes.

Pero la actitud de Carl Harris fue aún más importante. Él entendió que

5. Cuando se pierde el interés en un programa, el último deber es heredarlo 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 nosostros 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.
3 La importancia de contar con usuarios

Así fue como heredé popclient. Además, recibí su base de usuarios, lo cual fue tan 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. Copn 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.

6. 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 eradica 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ó quedito una frase que ha dicho muchas veces: "B&aacutesicamente soy una persona muy floja que le gusta obtener el crédito por lo que, realmente, hacen" los demás. Flojo como una zorra. 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 rescribí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.

Es más, uno de mis programas con mayor exito, antes de fetchmail, fue probablemente el modo VC para Emacs, una colaboración tipo Linux, que realice por correo electrónico conjuntamente con otras tres personas, de las cuales solamente he conocido a una (Richard Stallman) hasta la fecha. VC era una 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 desarrollaba de un pequeño y, hasta cierto punto, rudimentario modo sccs.el 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.

(Uno de los efectos colaterales de la política de la FSF de atar legalmente el c&oacutedigo a la GPL, fue que se volvió más difícil para la FSF usar el modo bazar, debido a su idea de que se deb&iacuten de asignar derechos de autor por cada contribución individual de más de veinte líneas, a fin de inmunizar al código protegido por la GPL de cualquier problema legal surgido de ley de derechos de autor. Los usuarios de las licencias BSD y del MIT X Consortium no tienen este problema, debido a que no intentan reservarse derechos que cualquiera intente poner en duda.)
4 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, en 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í que liberar una vez cada seis meses (o aún con menos frecuencia) 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. Pero solamente algunos de nosotros reflexionamos realmente acerca de lo que estábamos haciendo, o de lo que la simple existencia del archivo sugería sobre los problemas implícitos en el modelo de desarrollo estilo catedral de la FSF. Yo realicé un intento serio, alrededor de 1992, de unir formalmente buena parte del código de Ohio con la biblioteca Lisp oficial del Emacs. Me metí en broncas políticas muy serias y no tuve éxito.

Pero un año después, a medida que Linux se agigantaba, quedo claro que estaba pasando algo distinto y mucho más sano. La política abierta de desarrollo de Linus era lo más opuesto a la construcción estilo catedral. Los repositorios de archivos en sunsite y tsx-11 mostraban una intensa actividad y muchas distribuciones de Linux circulaban. Y todo esto se manejaba con una frecuencia en la publicación de programas que no tenía precedentes.

Linus estaba tratando a sus usuarios como colaboradores de la forma más efectiva posible:

7. Libere rápido y a menudo, y escuche a sus clientes.

La innovación de Linus no consistió tanto en esto (algo parecido había venido sucediendo en la tradición del mundo UNIX desde hacía tiempo), sino en llevarlo a un nivel de intensidad que estaba acorde con la complejidad de lo que estaba desarrollando. ¡En ese entonces no era raro que liberara una nueva versión del kernel más de una vez al día! Y, debido a que cultivó su base de desarrolladores asistentes y buscó colaboración en la Internet más intensamaente que ningún otro, funcionó.

¿Pero cómo fue que funcionó? ¿Era algo que yo podía emular, o se debía a la genialidad única de Linus?

No lo considero así. Está bien, Linus es un hacker endiabladamente astuto (¿cuántos de nosotros podrían diseñar un kernel de alta calidad?). Pero Linux en sí no representa ningún salto conceptual sorprendente hacia delante. Linus no es (al menos, no hasta ahora) un genio innovador del diseño como lo son Richard Stallman o James Gosling. En realidad, para mi Linus es un genio de la ingeniería; tiene un sexto sentido para evitar los callejones sin salida en el desarrollo y la depuración, y es tipo muy sagaz para encontrar el camino con el mínimo esfuerzo desde el punto A hasta el punto B. De hecho, todo el diseño de Linux transpira esta calidad, y refleja un Linus conservador que simplifica el enfoque en el diseño.

Por lo tanto, si las publicaciones frecuentes del código y la búsqueda de asistencia dentro de la Internet no son accidentes, sino partes integrales del ingenio de Linus para ver la ruta crítica del mínimo esfuerzo, ¿qué era lo que estaba maximizando? ¿Qué era lo que estaba exprimiendo de la maquinaria?

Planteada de esta forma, las pregunta se responde por sí sola. Linus estaba manteniendo a sus usuarios-hackers-asistentes constantemente estimulados y recompensados por la perspectiva de tomar parte en la acción y satisfacer su ego, premiado con la exhibición y mejora constante, casi diaria, de su trabajo.

Linus apostaba claramente a maximizar el número de horas-hombre invertidas en la depuración y el desarrollo, a pesar del riesgo que corría de volver inestable el código y agotar a la base de usuarios, si un error serio resultaba insondable. Linus se portaba como si creyera en algo como esto:

8. 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.

O, dicho de manera menos formal, "con muchas miradas, todos los errores saltarán a la vista". A esto lo he bautizado como la Ley de Linus.

Mi formulación original rezaba que todo problema deberá ser transparente para alguien. Linus descubrió que la personas que entendían y la que resolvían un problema no eran necesariamente las mismas, ni siquiera en la mayoría de los casos. Decía que "alguien encuentra el problema y otro lo resuelve". Pero el punto está en que ambas cosas suelen suceder con gran rapidez.

Aquí, pienso, subyace una diferencia esencial entre el estilo del bazar y el de la catedral. En el enfoque estilo catedral de la programación, los errores y problemas de desarrollo son fenómenos truculentos, insidiosos y profundos. Generalmente toma meses de revisión exhaustiva para unos cuantos el alcanzar la seguridad de que han sido eliminados del todo. Por eso se dan los intervalos tan largos entre cada versión que se libera, y la inevitable desmoralización cuando estas versiones, largamente esperadas, no resultan perfectas.

En el enfoque de programación estilo bazar, por otro lado, se asume que los errores son fenómenos relativamente evidentes o, por lo menos, que pueden volverse relativamente evidentes cuando se exhiben a miles de entusiastas desarrolladores asistentes que colaboran al parejo sobre cada una de las versiones. En consecuencia, se libera con frecuencia para poder obtener una mayor cantidad de correcciones, logrando como efecto colateral benéfico el perder menos cuando un eventual obstáculo se atraviesa.

Y eso es todo. Con eso basta. Si la Ley de Linus fuera falsa, entonces cualquier sistema suficientemente complejo como el kernel de Linux, que está siendo manipulado por tantos, debería haberse colapsado en un punto bajo el peso de ciertas interacciones imprevistas y errores "muy profundos" inadvertidos. Pero si es cierta, bastaría para explicar la relativa ausencia de errores en el código de Linux.

Despu&aecute;s de todo, esto no debí parecernos tan sorpresivo. Hace algunos años los sociólogos descubrieron que la opinión promedio de un numero grande de observadores igualmente expertos (o igualmente ignorantes) es más confiable de predecir que la de uno de los observadores seleccionado al azar. A esto se le conoce como el efecto Delphi. Al parecer, lo que Linus ha demostrado es que esto también es valedero en el ámbito de la depuración de un sistema operativo: que el efecto Delphi puede abatir la complejidad implícita en el desarrollo, incluso al nivel de la involucrada en el desarrollo del núcleo de un OS.

Estoy en deuda con Jeff Dutky dutky@wam.umd.edu, quien me sugirió que la Ley de Linus puede replantearse diciendo que "la depuración puede hacerse en paralelo". Jeff señala que a pesar de que la depuración requiere que los participantes se comuniquen con un programador que coordina el trabajo, no demana ninguna coordinación significativa entre ellos. Por lo tanto, no cae víctima de la asombrosa complejidad cuadr&acaute;tica y los costos de maniobra que ocasionan que la incorporación de desarrolladores resulte problemática.

En la práctica, la pérdida teórica de eficiencia debido a la duplicación del trabajo por parte de los programadores casi nunca es un tema que revista importancia en el mundo Linux. Un efecto de la "política de liberar rápido y a menudo" es que esta clase de duplicidades se minimizan al propagarse las correcciones rápidamente.

Brooks hizo una observación relacionada con la de Jeff: "El costo total del mantenimiento de un programa muy usado es típicamente alrededor del 40 por ciento o más del costo del desarrollo. Sorpresivamente, este costo está fuertemente influenciado por el número de usuarios. Más usuarios detectan una mayor cantidad de errores." (El subrayado es mío).

Una mayor cantidad de usuarios detecta más errores debido a que tienen diferentes maneras de evaluar el programa. Este efecto se incrementa cuando los usuarios son desarrolladores asaitentes. Cada uno enfoca la tarea de la caracterización de los errores con un bagaje conceptual e instrumentos analíticos distintos, desde un ángulo diferente. El efecto Delphi parece funcionar precisamente debido a estas diferencias. En el contexto específico de la depuración, dichas diferencias también tienden a reducir la duplicación del trabajo.

Por lo tanto, el agregar más beta-testers podría no contribuir a reducir la complejidad del "más profundo" de los errores actuales, desde el punto de vista del desarrollador, pero aumenta la probabilidad de que la caja de herramientas de alguno de ellos se equipare al problema, de tal suerte que esa persona vea claramente el error.

Linus también dobla sus apuestas. En el caso de que realmente existan errores serios, las versiones del kernel de Linux son enumeradas de tal manera que los usuarios potenciales puedan escoger la última versión considerada como "estable" o ponerse al filo de la navaja y arriesgarse a los errores con tal de aprovechar las nuevas características. Esta táctica no ha sido formalmente imitada por la mayoría de los hackers de Linux, pero quizá debían hacerlo. El hecho de contar con ambas opciones, lo vuelve aún más atractivo.
5 ¿Cuándo una Rosa no es Rosa?

Después de estudiar la forma en que actuó Linus y haber formulado una teoría del por qué tuvo éxito, tomé la decisión consciente de probarla en mi nuevo proyecto (el cual, debo admitirlo, es mucho menos complejo y ambicioso).

Lo primero que hice fue reorganizar y simplificar popclient. El trabajo de Carl Harris era muy bueno, pero exhibía una complejidad innecesaria, típica de muchos de los programadores en C. Él trataba el código como la parte central y las estructuras de datos como un apoyo para éste. Como resultado, el código resultó muy elegante, pero el diseño de las estructuras de datos salió ad hoc y feo (por lo menos con respecto a los estándares exigentes de este viejo hacker de Lisp).

Sin embargo, tenía otro motivo para reescribir, además de mejorar el diseño de la estructura de datos y el código: El proyecto debía evolucionar en algo que yo entendiera cabalmente. No es nada divertido ser el responsable de corregir los errores en un programa que no se entiende.

Por lo tanto, durante el primer mes, o algo así, simplemente fui siguiendo los pormenores del diseño básico de Carl. El primer cambio serio que realicé fue agregar el soporte de IMAP. Lo hice reorganizando los administradores de protocolos en un administrador genérico con tres tablas de métodos (para POP2, POP3 e IMAP). Éste y algunos cambios anteriores muestran un principio general que es bueno que los programadores tengan en mente, especialmente los que programan en lenguajes tipo C y no hacen manejo de datos dinámicamente:

9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.

De nuevo, Fred Brooks, Capítulo 11: "Muéstreme su código y esconda sus estructuras de datos, y continuaré intrigado. Muéstreme sus estructuras de datos y generalmente no necesitaré ver su código; resultará evidente.''

En realidad, él hablaba de "diagramas de flujo" y "tablas". Pero, con treinta años de cambios terminológicos y culturales, resulta prácticamente la misma idea.

En este momento (a principios de septiembre de 1996, aproximadamente seis semanas después de haber comenzado) empecé a pensar que un cambio de nombre podría ser apropiado. Después de todo, ya no se trataba de un simple cliente POP. Pero todavía vacilé, debido a que no había nada nuevo y genuinamente mío en el diseño. Mi versión del popclient tenía aún que desarrollar una identidad propia.

Esto cambio radicalmente cuando fetchmail aprendió a remitir el correo recibido al puerto SMTP. Volveré a este punto en un momento. Primero quiero decir lo siguiente: yo afirmé anteriormente que decidí utilizar este proyecto para probar mi teoría sobre la correción del estilo Linus Torvalds. ¿Cómo lo hice? (podrían ustedes preguntar muy bien). Fue de la siguiente manera:

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.

La recompensa por estas simples medidas fue inmediata. Desde el principio del proyecto obtuve reportes de errores de calidad, frecuentemente con buenas soluciones anexas, que envidiarían la mayoría de los desarrolladores. Obtuve crítica constructiva, mensajes de admiradores e inteligentes sugerencias. Lo que lleva a la siguiente lección: