Aviso: Faz mais de um ano e meio que comecei a escrever esse artigo e o estou publicando pois me cansei de vê-lo em minha lista de rascunhos. Se você tem um tempo livre ou não, eu sugiro que, após ler esse artigo, você vá arrumar uma cópia de “A catedral e o bazar” e vá lê-la. Vale a pena e a leitura é tranqüila. Há, inclusive, uma versão em Português, mas se você sabe um pouco de inglês, eu sugiro a leitura da versão original.

Recentemente eu li o livro A catedral e o bazar, de Eric Raymond. Esse texto foi importante para que os executivos da Netscape Corporation decidissem liberar o código-fonte do navegador que se tornaria o Mozilla (e que agora deu origem ao Firefox). Logo se trata de um texto, no mínimo, interessante.

Durante todo o texto, Raymond apresenta o “modelo bazar” de desenvolvimento de software, que ele aprendeu ao observar o desenvolvimento do Linux, que pode não ser o melhor Sistema Operacional existente, mas que com certeza se tornou o livre mais popular graças a este estilo de programação e a sua comunidad extremamente ativa. Durante o livro, Raymond apresenta as lições aprendidas que podem ser aplicadas no desenvolvimento de um projeto de Software Livre.

Vamos, então, às lições:

1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador;
2. Bons programadores sabem o que escrever. Os grandes sabem o quê re-escrever (e como);
3. Planeje-se para jogar fora uma versão; você irá, de qualquer forma (Dizendo de outra forma, normalmente você não conhece bem um problema até que tenha implementado uma solução. Na segunda vez, talvez você saiba o suficiente para fazer direito);
4. Se você tem a postura correta, problemas interessantes te encontrarão;
5. Quando você perde o interesse em um programa, seu último dever é o de passá-lo a um sucessor competente;
6. Tratar os seus usuários como co-desenvolvedores é a rota com menos problemas para aperfeiçoamento rápido de código e debug efetivo;
7. Libere o software cedo. Libere o software de vez em quando. E ouça seus consumidores;
8. Dados uma base de beta-testers e co-desenvolvedores grande o suficiente, quase todos os problemas serão caracterizados rapidamente e a solução será óbvia para alguém;
9. Estruturas de dados inteligentes e código idiota funcionam muito melhor que o contrário;
10. Se você tratar seus beta-testers como seu recurso mais importante, eles se tornarão seu recurso mais importante;
11. A próxima melhor coisa depois de ter boas idéias e reconhecer boas idéias de seus usuários. Às vezes o último é melhor;
12. Às vezes, as soluções mais importantes e inovadoras vêm de perceber que seu conceito do problema estava errado;
13. A perfeição (no projeto) não é alcançada quando não há nada mais para adicionar, mas quando não há mais nada para retirar;
14. Qualquer ferramenta deve ser útil da maneira que é esperada, mas uma ferramenta realmente boa pode ser usada de maneiras que nunca poderiam ser esperadas;
15. Quando você escrever software de gateway, façao máximo para perturbar o fluxo de dados o mínimo possível — e nunca jogue informação fora, a menos que o recipiente o force a fazer isso;
16. Se sua linguagem não é computacionalmente universal, açúcar sintático pode ser seu amigo;
17. Um sistema de segurança é seguro se for secreto, cuidado com pseudo-segredos;
18. Para resolver um problema interessante, comece encontrando um problema que é interessante para você;
19. Dado que o coordenador do desenvolvimento possui um meio de comunicação no mínimo tão bom quanto a Internet e saiba liderar sem coagir, muitas cabeças são melhores que uma;

Essas lições são publicadas mais como um lembrete para mim, mas espero que possam estimular outras pessoas por aí. Para terminar, uma outra citação do cara: “Mostre-me seu código e esconda suas estruturas de dados e esconda seu código e eu continuarei cego. Mostre-me suas estruturas de dados e oculte seu código e eu provavelmente não precisarei dele”. (Pra ser sincero eu não lembro onde eu li isso, então a citação não está 100% correta)