La Catedral y el Bazar - 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.