Siguiente Anterior Indice 

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 cerece 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 dí 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 abilidad 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 alegremente a un inexistente 'joe' en "snark". Editar a mano las direcciones de las respuestas para restaurar 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 secció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:

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

2. Los buenos programadores saben qué escribir. Los grandes saben qué reescribir (y reutilizar).

Aunque no pretendo ser un gran programador, trato de imitarlos. Una característica importante de los grandes de verdad es la vagancia constructiva. Saben que te dan un diez no por tu esfuerzo, sino por los resultados, y es casi siempre más fácil empezar a partir de una buena solución parcial que desde la nada más absoluta.

Linus, sin ir más lejos, no intentó en realidad escribir Linux partiendo de cero. En vez de eso, comenzó reutilizando código e ideas de Minix, un minúsculo simil de Unix para máquinas 386. Al final, todo el código Minix fue desechado o se reescribió por completo -- pero mientras estuvo allí proporcionó el andamiaje necesario para la criatura que eventualmente llegaría a ser Linux.

En la misma línea, comencé a buscar una herramienta POP ya existente que estuviera razonablemente bien programada para utilizarla como punto de partida.

La tradición Unix de compartir el código fuente ha facilitado la reutilización del código (es la razón por la que el proyecto GNU
eligió Unix como sistema operativo de partida, a pesar de tener serias reservas sobre el mismo). El mundo Linux ha llevado
esta tradición muy cerca de su límite desde el punto de vista tecnológico; pues cuenta con terabytes de código fuente de uso
libre. Es por eso por lo que es más probable que invertir tiempo en la búsqueda de algo casi lo suficientemente bueno realizado
por otro de mejores resultados que en ningun otro lugar.

Y a mí me lo dió. Con los que ya había encontrado anteriormente, mi segunda búsqueda elevó el total a nueve candidatos --
fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail y upop. Al principio me quedé con 'fetchpop' de
Seung-Hong Oh. Le añadi´ mi característica de reescribir las cabeceras, y le hice algunas otras mejoras que fueron
aceptadas por el autor e incorporadas a la versión 1.9.

Sin embargo, algunas semanas después cayó en mis manos el código de `popclient' de Carl Harris, y supe que tenía un
problema. Aunque 'fetchpop' contaba con algunas ideas originales (su modo demon, sin ir más lejos), sólo era capaz de
manejar POP3 y estaba codificado de una forma no demasiado seria (Seung-Hong era un programador brillante pero poco
experimentado, y ambas características quedaban claramente de manifiesto). El código de Carl era mejor, bastante
profesional y sólido, pero su programa carecía de varias posibilidades importantes y bastante puñeteras de implementar con
las que contaba 'fetchpop' (entre ellas las que yo le había añadido).

¿Seguir o cambiar?. Si cambiaba, tenía que renunciar al código que ya había desarrollado a cambio de una mejor base para el
futuro.

Una razón práctica para realizar el cambio era la presencia de soporte para protocolos múltiples. POP3 es el que se usa más
comunmente, pero no el único. 'Fetchpop' y los demás competidores no soportaban POP2, RPOP o APOP, y yo albergaba ya
alguna remota intención de añadir tal vez IMAP (Internet Message Access Protocol, el protocolo más reciente y potente para
oficinas de correo) aunque solo fuera como diversión.

Pero tenía una razón teórica adicional para pensar que cambiar podíia ser también una buena idea, algo que aprendí mucho
antes de llegar a Linux.

3. ``Piensa en desechar al menos uno: lo terminarás haciendo de todos modos.'' (Fred Brooks, ``The Mythical
Man-Month'', Capítulo 11)

O, por decirlo de otra manera, a menudo no entiendes un problema hasta después de haber implementado una primera
solución. La segunda vez, tal vez sepas lo suficiente como para hacerlo bien. Por tanto, si lo quieres hacer bien, debes estar
preparado para empezar al menos dos veces.

Bueno (me dije) es posible que 'fetchpop' haya sido mi primer intento. Y cambié.

Tras enviar mi primera remesa de modificaciones a 'popclient' a Carl Harris el 25 de Junio de 1996, me di cuenta de que hacía
ya algún tiempo que él había perdido interés en 'popclient'. El código se veía un tanto polvoriento, con algunos errores
menores dando vueltas por ahí. Tenía muchas modificaciones que hacer, y nos pusimos de acuerdo con rapidez en que lo más
lógico era que me hiciera cargo del programa.

Sin darme cuenta, la escala del proyecto había cambiado. Ya no se trataba de realizar pequeñas modificaciones a un cliente
POP ya existente, sino de mantener uno por completo, y sabía que por si fuera poco algunas de las ideas que bullían en mi
cabeza conducían a cambios drásticos.

En una cultura que promueve compartir código esta es la forma natural en que evoluciona un proyecto. La cosa funcionaba
del siguiente modo:

4. Si tienes la actitud adecuada, los problemas interesantes te encontrarán

Pero la actitud de Carl Harris era incluso más importante. Entendía que...

5. Cuando un programa deja de interesarte, tu último deber es pasarlo a un sucesor competente.

Sin tener que entrar en discusiones, Carl y yo sabíamos que compartíamos el propósito de desarrollar la mejor solución de
todas al problema que nos ocupaba. El único punto a aclarar era si yo era un sucesor digno. Una vez que quedó claro, actuó
con gracia y determinación. Espero ser capaz de actuar de la misma forma cuando llegue mi turno.


Siguiente Anterior Indice