A Catedral e o Bazar/VII
Traduzido por Erik Kohler. <ekohler at programmer.net>
Lá estava eu com um projeto elegante e inovador, um código que eu sabia que funcionava bem porque eu usava todos os dias, e uma crescente lista de beta testers. E gradualmente eu percebia que eu não estava mais ocupado com uma trivial codificação pessoal que porventura poderia se tornar útil para algumas pessoas. Eu tinha em minhas mãos um programa que todos os usuários de um sistema Unix com uma conexão de correio SLIP/PPP realmente precisavam.
Com a característica de reenvio por SMTP, ele passou muito à frente da competição para potencialmente se tornar um "category killer", um destes programas clássicos que preenchem seu nicho tão completamente que as alternativas não são somente descartadas como também esquecidas.
Eu penso que você não pode realmente almejar ou planejar um resultado como este. Você tem que ser atraído para isso por idéias de projeto tão poderosas que posteriormente os resultados parecem inevitáveis, naturais, mesmo predestinados. A única maneira de tentar idéias como esta é tendo muitas idéias -- ou tendo o julgamento de engenharia para levar as boas idéias das outras pessoas além do que estas que as tiveram pensariam que elas poderiam ir.
Andrew Tanenbaum teve a idéia original de construir um Unix nativo simples para o 386, para uso como uma ferramenta de ensino. Linus Torvalds levou o conceito do Minix para além do que Andrew provavelmente pensou que poderia ir -- e cresceu para algo maravilhoso. Da mesma forma (embora em uma menor escala), eu peguei algumas idéias de Carl Harris e Harry Hochheiser e dei um empurrão. Nenhum de nós foi 'original' no sentido romântico que as pessoas pensam é um gênio. Mas a maioria do desenvolvimento de software científico e de engenharia não é feita por um gênio original, a mitologia hacker ao contrário.
Os resultados foram todos sempre muito precipitados -- de fato, o tipo de sucesso que qualquer hacker está sempre procurando! E eles significaram que eu teria que definir meus padrões ainda mais altos. Para fazer o fetchmail tão bom como eu então achava que poderia se tornar, eu teria que escrever não somente para minhas próprias necessidades, mas também incluir e suportar características necessárias para outros fora do meu relacionamento. E fazer isto mantendo o programa simples e robusto.
A primeira e mais importante esmagadora característica que eu escrevi depois de perceber isto foi o suporte a multidrop -- a habilidade de capturar correio de caixas de correio que acumularam todas as mensagens para um grupo de usuários, e então destinar cada pedaço de correio para seus destinatários individuais.
Eu decidi adicionar o suporte ao multidrop em parte porque alguns usuários estavam pedindo por isto, mas principalmente porque eu pensei que isto iria retirar os erros do código para o envio simples me forçando a manipular o endereçamento de um modo geral. E assim se provou ser. Fazer funcionar a análise da RFC 822 me tomou um tempo consideravelmente longo, não porque qualquer pedaço dele é difícil mas porque envolvia uma pilha de detalhes interdependentes e elaborados.
Mas o endereçamento multidrop se tornou uma decisão de projeto excelente. Aqui está como eu soube:
14. Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta verdadeiramente "boa" leva ela própria a usos que você nunca esperou.
O uso inesperado para o multidrop do fetchmail é executar mailing lists com a lista mantida, e expansão de apelidos feita, no lado do cliente da conexão SLIP/PPP. Isto significa que alguém executando uma máquina pessoal por uma conta ISP pode administrar uma mailing list sem acesso contínuo aos arquivos de apelidos do ISP.
Outra importante mudança solicitada pelos meus beta testers foi suporte para operação MIME 8-bit. Isto foi muito fácil de fazer, porque eu estava sendo cuidadoso mantendo o código pronto para 8-bit. Não porque eu antecipei a demanda para esta característica, mas em obediência a outra regra:
15. Quando escrevendo um software gateway de qualquer tipo, faça tudo para perturbar o conjunto de dados o menos possível -- e "nunca" jogue fora informação a não ser que o destinatário force você a isto!
Se eu não tivesse obedecido esta regra, o suporte a MIME 8-bit teria sido difícil e cheio de erros. Como estava, tudo o que tive que fazer foi ler a RFC 1652 e adicionar um pouco de lógica trivial para a geração de cabeçalho.
Alguns usuários Europeus insistiram para que eu adicionasse uma opção para limitar o número de mensagens recebidas por seção (de maneira que eles poderiam controlar custos das suas caras redes de telefone). Eu resisti por um longo tempo, e ainda não estou inteiramente alegre sobre isto. Mas se você está escrevendo para o mundo, você tem que ouvir os seus clientes -- isto não muda somente porque eles não estão pagando dinheiro a você.