A Catedral e o Bazar/V: diferenças entre revisões

Wikisource, a biblioteca livre
Conteúdo apagado Conteúdo adicionado
m Bot: Adicionando: it
m Bot: Mudança automática (-=A Catedral e o Bazar +=A Catedral e o Bazar)
Linha 3: Linha 3:
|posterior=[[A Catedral e o Bazar/VI|VI: Popclient transforma-se em Fetchmail]]
|posterior=[[A Catedral e o Bazar/VI|VI: Popclient transforma-se em Fetchmail]]
|seção=Quando Uma Rosa Não é Uma Rosa?
|seção=Quando Uma Rosa Não é Uma Rosa?
|obra=A Catedral e o Bazar
|obra=[[A Catedral e o Bazar]]
|autor=Eric S. Raymond
|autor=Eric S. Raymond
|notas=Cópia e redistribuição permitida sem royalty contanto que esta notificação esteja preservada.
|notas=Cópia e redistribuição permitida sem royalty contanto que esta notificação esteja preservada.

Revisão das 20h38min de 15 de outubro de 2006

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.