Desde 1993 eu venho cuidando da parte técnica de um pequeno Provedor de Acesso Internet de acesso gratuito chamado Chester County InterLink (CCIL) em West Chester, Pensilvânia (eu fui co-fundador do CCIL e escrevi nosso software multiusuário de BBS - você pode observá-lo executando um telnet para locke.ccil.org. Hoje suporta quase três mil usuários em trinta linhas.) O trabalho permitiu-me o acesso 24 horas por dia à rede através da linha de 56K do CCIL - de fato, praticamente exigiu!

Conseqüentemente, eu fiquei acostumado a acesso instantâneo ao correio Internet. Por razões complicadas, era difícil fazer o SLIP funcionar entre minha máquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, eu achei incômodo ter que executar telnet periodicamente para o locke para verificar meu correio. O que eu queria era que ele fosse enviado para o snark de modo que eu fosse notificado quando uma mensagem chegasse e pudesse manuseá-lo usando todas as minhas ferramentas locais.

O simples reenvio do sendmail não funcionaria, porque minha máquina local não está sempre na rede e não tem um IP estático. O que eu precisava era um programa que pegasse meu correio através da conexão SLIP e o entregasse localmente. Eu sabia que tais programas existiam, e que a maioria deles usava um protocolo de aplicação simples chamado POP (Post Office Protocol). E, realmente, já havia um servidor POP3 incluído com sistema operacional BSD/OS do locke.

Eu precisava de um cliente POP3. Então eu procurei na Internet e encontrei um. Na verdade, eu encontrei três ou quatro. Eu usei o pop-perl por algum tempo, mas faltava o que parecia uma característica óbvia, a habilidade de alterar os endereços no correio recebido para que as respostas fossem enviadas corretamente.

O problema era este: suponha que alguém chamado `joe' no locke tenha me enviado uma mensagem. Se eu capturasse o correio para o snark e tentasse então lhe responder, meu programa de correio tentaria alegremente enviá-lo a um `joe' inexistente no snark. Editar manualmente os endereços de resposta para adicionar `@ccil.org ' rapidamente tornou-se um tormento.

Isto era claramente algo que o computador teria que fazer para mim. Mas nenhum dos clientes POP existentes sabiam como! E isto nos traz à primeira lição:

1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador.

Talvez isto deveria ter sido óbvio (um antigo provérbio diz que "A necessidade é a mãe da invenção") mas muitas vezes os programadores gastam seus dias buscando retorno em programas que eles não necessitam nem gostam. Mas não no mundo do Linux - o que pode explicar porque a qualidade média do software originada na comunidade de Linux é tão alta.

Assim, eu me lancei imediatamente com o ímpeto de codificar um novo cliente POP3 para competir com os existentes? De maneira alguma! Eu olhei com cuidado os utilitários POP que eu tinha à disposição, perguntando-me "qual deles é o mais próximo do que eu quero?. Porque...

2. Os programadores bons sabem o que escrever. O grandes sabem o que reescrever (e reusar).

Embora eu não me considere um grande programador, eu tento me passar por um. Uma importante característica dos grandes é a preguiça construtiva. Eles sabem que você ganha um 'A' não por esforço, mas por resultados, e é quase sempre mais fácil partir de uma boa solução parcial do que do nada.

Linus Torvalds, por exemplo, não tentou realmente escrever Linux do nada. Ao contrário, ele começou reusando código e idéias do Minix, um pequeno sistema operacional Unix-like para máquinas 386. Eventualmente todo o código Minix se foi ou foi completamente reescrito - mas quando estava lá, forneceu as bases para o infante que se transformaria no Linux.

Com o mesmo pensamento, eu fui procurar um utilitário POP que fosse razoavelmente bem codificado, para usar como uma base de desenvolvimento.

A tradição do mundo Unix de compartilhar o código fonte foi sempre amigável para a reutilização de código (esta é a razão porque o projeto de GNU escolheu o Unix como sistema operacional base, apesar das sérias reservas sobre o mesmo). O mundo Linux tem levado esta tradição quase a seu limite tecnológico; tem terabytes de códigos abertos amplamente disponíveis. Assim gastando tempo procurando algum software quase-bom-o-bastante feito por alguém é mais provável dar a você mais bons resultados no mundo Linux do que em qualquer outro lugar.

E fez para mim. Com aqueles que eu achei antes, minha segunda busca compôs um total de nove candidatos - fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail e upop. O primeiro que eu trabalhei primeiramente era o 'fetchpop' por Seung-Hong Oh. Eu pus o meu código de reescrita de cabeçalho nele, e fiz várias outras melhorias que o autor aceitou em sua versão 1.9.

Algumas semanas mais tarde, entretanto, eu tropecei pelo código do 'popclient' desenvolvido por Carl Harris, e descobri que eu tinha um problema. Embora o fetchpop tenha tido algumas idéias boas e originais (tal como o modo daemon), podia somente trabalhar com POP3 e foi codificado de uma maneira um tanto amadora (Seung-Hong era um programador brilhante porém inexperiente, e ambas as características ficaram evidentes). O código de Carl era melhor, bastante profissional e sólido, mas em seu programa faltou diversas características importantes e complicadas de serem implementadas do fetchpop (incluindo aquelas que eu implementei).

Ficar ou trocar? Se eu trocasse, eu estaria jogando fora o código que eu já havia feito em troca de uma base melhor do desenvolvimento.

Um motivo prático para trocar era a presença de suporte para vários protocolos. POP3 é o protocolo mais comumente utilizado de todos os protocolos de correio dos servidores, mas não o único. Fetchpop e os outros concorrentes não faziam POP2, RPOP ou APOP, e eu estava realmente tendo alguns pensamentos de talvez adicionar IMAP (Internet Message Access Protocol ou Protocolo de Acesso a Mensagem da Internet, o mais recente e poderoso protocolo de correio desenvolvido) só para me divertir.

Mas eu tinha uma razão mais teórica para pensar que trocar seria uma boa idéia, alguma coisa que eu aprendi muito antes do Linux.

3. "Planeje jogar algo fora; você irá, de qualquer maneira". (Fred Brooks, "The Mythical Man-Month", Capítulo 11)

Ou, colocando de outra forma, você freqüentemente não entende realmente o problema até depois da primeira vez que você implementa uma solução. Na segunda vez, talvez você saiba o suficiente para fazer corretamente. Então se você quer fazer algo certo, esteja preparado para começar tudo novamente pelo menos uma vez.

Bem (eu disse para mim mesmo) as mudanças no fetchpop foram a minha primeira tentativa. Então eu troquei.

Depois que eu mandei meu primeiro conjunto de alterações para Carl Harris em 25 de junho de 1996, eu percebi que na verdade ele perdera o interesse pelo popclient há algum tempo até então. O código era um pouco empoeirado, com pequenos erros. Eu tinha muitas mudanças para fazer, e nós rapidamente concordamos que o lógico para eu fazer era tomar conta do programa.

Sem perceber, o projeto havia se intensificado. Eu não estava mais contemplando somente pequenos consertos para um cliente POP existente. Eu estava mantendo um cliente completo, e havia idéias borbulhando na minha cabeça que eu sabia iriam provavelmente levar a importantes mudanças.

Em uma cultura de software que encoraja a troca de código, isto é um caminho natural para um projeto evoluir. Eu estava representando isto:

4. Se você tem a atitude certa, problemas interessantes irão encontrá-lo.

Mas a atitude do Carl Harris foi ainda mais importante. Ele entendeu que

5. Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente.

Sem ao menos ter que discutir isso, Carl e eu sabíamos que nós tínhamos um objetivo em comum de ter a melhor solução disponível. A única questão para nós foi se eu poderia me estabelecer como um par de mãos seguras para isso. Uma vez que eu tenha feito isso, ele agiu com cortesia e rapidez. Eu espero que eu aja assim quando chegar a minha vez.