Aviso: Faz mais de um ano e meio que comecei a escrever esse texto
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:
Todo bom trabalho de software começa colocando o dedo na ferida de
um programador;
Bons programadores sabem o que escrever. Os grandes sabem o quê
re-escrever (e como);
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);
Se você tem a postura correta, problemas interessantes te encontrarão;
Quando você perde o interesse em um programa, seu último dever é o
de passá-lo a um sucessor competente;
Tratar os seus usuários como co-desenvolvedores é a rota com menos
problemas para aperfeiçoamento rápido de código e debug efetivo;
Libere o software cedo. Libere o software de vez em quando. E ouça
seus consumidores;
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;
Estruturas de dados inteligentes e código idiota funcionam muito
melhor que o contrário;
Se você tratar seus beta-testers como seu recurso mais importante,
eles se tornarão seu recurso mais importante;
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;
Às vezes, as soluções mais importantes e inovadoras vêm de perceber
que seu conceito do problema estava errado;
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;
Qualquer ferramenta deve ser útil da maneira que é esperada, mas uma
ferramenta realmente boa pode ser usada de maneiras que nunca
poderiam ser esperadas;
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;
Se sua linguagem não é computacionalmente universal, açúcar
sintático pode ser seu amigo;
Um sistema de segurança é seguro se for secreto, cuidado com pseudo-segredos;
Para resolver um problema interessante, comece encontrando um
problema que é interessante para você;
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)