Sem dúvida que é um marco para o mundo open source. Publicada por Eric S. Raymond e traduzida para o português por Erik Kohler, A Catedral e o Bazar conta toda a história e os primeiros passos do movimento Open Source.
Tendo estudado o comportamento do Linus e formado uma teoria sobre como ele foi bem sucedido, eu fiz uma decisão consciente para testar esta teoria em meu novo (reconhecidamente muito menos complexo e ambicioso) projeto.
Mas a primeira coisa que eu fiz foi reorganizar e simplificar bastante o popclient. A implementação do Carl Harris era muito atrativa, mas exibia um tipo de complexidade desnecessária comum a vários programadores em C. Ele tratou o código como centro das atenções e as estruturas de dados como suporte para o código. Como resultado, o código era muito bonito mas o projeto da estrutura de dados era ad-hoc e um tanto feio (pelo menos pelos altos padrões deste velho hacker de LISP).
Eu tinha outro propósito para reescrever além de aperfeiçoar o código e o projeto da estrutura de dados, entretanto. Era evoluí-lo para algo que eu entenderia completamente. Não é nada agradável ser responsável por consertar erros em um programa que você não entende.
Mais ou menos durante o primeiro mês, então, eu estava simplesmente seguindo as implicações do projeto básico do Carl. A primeira mudança séria que fiz foi adicionar suporte ao IMAP. Eu fiz isso reorganizando as rotinas de protocolos em um driver genérico e três tabelas de métodos (para POP2, POP3 e IMAP). Esta e as mudanças anteriores ilustram o princípio geral que é bom para os programadores manterem em mente, especialmente em linguagens como C que não implementam naturalmente tipagem dinâmica:
9. Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário.
Brooks, Capítulo 11: "Mostre-me seu [código] e esconda suas [estruturas de dados], e eu poderei continuar mistificado. Mostre-me suas [estruturas de dados], e eu provavelmente não necessitarei do seu [código]; ele será óbvio."
De fato, ele disse "gráficos" e "tabelas". Mas considerando trinta anos de terminologias/mudanças culturais, é praticamente o mesmo ponto.
Neste ponto (quase Setembro de 1996, mais ou menos seis semanas desde o início) eu comecei a pensar que uma mudança de nome deveria ser adequada - afinal de contas, não era mais somente um cliente POP. Mas eu hesitei, porque ainda não havia ainda nada genuinamente novo ainda no projeto. Minha versão do popclient ainda teria que desenvolver uma identidade própria.
Isto mudou, radicalmente, quando o fetchmail aprendeu como reenviar mensagens recebidas para a porta SMTP. Eu irei a este ponto em um momento. Mas primeiro: Eu disse acima que eu decidi usar este projeto para testar minha teoria sobre o que Linus Torvalds fez corretamente. Como (você pode perguntar) eu fiz isto? Desta forma:
1. Eu liberei cedo e freqüentemente (quase nunca menos que uma vez a cada dez dias; durante períodos de desenvolvimento intenso, uma vez por dia). 2. Eu aumentei minha lista de beta testers adicionando à ela todo mundo que me contatava sobre o fetchmail. 3. Eu mandei extensos anúncios à lista de beta testers toda vez que eu liberava, encorajando as pessoas a participar. 4. E eu ouvia meus beta testers, questionando-os sobre decisões de desenvolvimento e incitando-os toda vez que eles mandavam consertos e respostas.
O retorno destas medidas simples foi imediato. Desde o início do projeto, eu obtive relatórios sobre erros de uma qualidade que a maioria dos desenvolvedores morreria para ter, muitas vezes com ótimos consertos incluídos. Eu obtive críticas severas, obtive mensagens de fãs, obtive sugestões inteligentes de características. O que leva a:
10. Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso.
Uma medida interessante do sucesso do fetchmail é o simples tamanho da lista de beta testers, amigos do fetchmail. Ao escrever este texto ela possuía 249 membros e são adicionados dois ou três por semana.
De fato, conforme eu reviso ao final de Maio de 1997, a lista está começando a perder membros depois do pico de aproximadamente 300 pessoas por uma razão interessante. Muitas pessoas têm me pedido para excluí-las da lista porque o fetchmail está trabalhando tão bem para elas que elas não precisam mais ver o tráfego da lista! Talvez isto seja parte do ciclo de vida normal de um projeto maduro do estilo bazar.
[8] Comentário enviado por fabio em 10/11/2006 - 12:03h
Fala GNU, neste caso apóio a publicação aqui no VOL. Motivo: a tradução está publicada no Geocities.
Possíveis problemas:
1. Geocities é beeeem mais lento que o VOL;
2. Vai que um dia a conta deixa de existir ou o artigo sai do ar.
Defendo que um texto, principalmente os úteis, estejam sempre espelhados em mais de 1 site, pois tudo nessa vida tem princípio, meio e fim e isso também vale para sites. É mais ou menos o conceito de mirrors de pacotes de distros, se só houvesse um, quando o servidor cair fica todo mundo na mão :)
[9] Comentário enviado por User-kuruma em 10/11/2006 - 14:23h
Excelente, esse texto tem aplicação não só na área de software, mas também traz lições para criação e desenvolvimento de projetos de outras áreas. As lições que se pode extrair do texto tem aplicação nas mais diversas áreas de produção e desenvolvimento de serviços para a sociedade em geral.
[11] Comentário enviado por yetlinux em 12/11/2006 - 23:36h
E como alguns já escreveram por aí, não aqui, que o site Domínio Público estaria com o pé na cova, nada melhor que relembrar o que ele pode ter de útil.