A obra original se divide em 14 capítulos, e está disponível online. Em “A catedral e o bazar”, Raymond analisa projetos de software livre e código aberto, com o objetivo de discutir as teorias sugeridas por Linus Torvald. Ao fazer isso, classifica códigos fechados como catedrais, ou seja, templos sagrados, imponentes, de difícil acesso. Enquanto os códigos abertos são bazares: todo mundo entra e, praticamente, têm vida própria. Dessa forma, o autor argumenta que “havendo olhos suficientes, todos os erros são óbvios” e finaliza a obra sugerindo a importância de comunidades de desenvolvedores e implicações para o futuro do software.
Os capítulos da obra são: a catedral e o bazar; o correio deve ser entregue; a importância de ter usuários; libere cedo, libere frequentemente. Seguidos por: quando uma Rosa não é uma Rosa?; popclient transforma-se em fetchmail; fetchmail cresce; algumas lições a mais do fetchmail; pré-condições necessárias para o estilo bazar e o contexto social do código aberto. Finalizando, enfim, com agradecimentos, indicações de leitura, o epílogo “Netscape ataca o bazar!” e um histórico de mudanças no artigo.
Eric Raymond, o autor, é um hacker, ícone do movimento Open Source e Software Livre. Ele também é responsável por manter “O dicionário dos hackers”. Além disso, ele trabalha com Software Livre desde 1982 e também contribuiu com a criação do Linux. Saiba mais sobre o autor em seu site, e se tiver interesse em conhecer “The Jargon File“, esse é o nome original do dicionário que ele mantém.
O bazar: as comunidades de desenvolvedores – movimentação para alcançar o software perfeito
No primeiro capítulo, o autor fala sobre como o Linux é revolucionário, porque funciona sem um controle “de cima”. E que, mesmo trabalhando com códigos abertos em mini-projetos, ficou admirado com o bom funcionamento dos repositórios do Linux, que recebia submissões de qualquer pessoa. E a partir desses estudos, em 1996, ele decidiu testar uma teoria baseada em código aberto. Portanto, é sobre essa teoria e seu teste, que o autor fala no resto do artigo.
Assim, no segundo capítulo ele mostra o que o levou a desenvolver esse grande projeto. Estava acostumado com a facilidade para se comunicar no trabalho, mas não possuía as mesmas ferramentas em casa. Portanto, precisava buscar uma solução para esse problema. Logo, ele apresenta cinco lições iniciais sobre programação:
- Todo bom trabalho de software começa colocando o dedo na ferida de um programador.
- Os programadores bons sabem o que escrever. Os grandes sabem o que reescrever (e reusar).
- “Planeje jogar algo fora; você irá, de qualquer maneira.” (Fred Brooks, “The Mythical Man-Month”, Capítulo 11).
- Se você tem a atitude certa, problemas interessantes irão encontrá-lo.
- Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente.
Portanto, nesse capítulo o autor fala sobre como a dificuldade que ele sentiu o fez procurar por algum programa já existente, que só precisasse de um apoio para ser melhorado; que no meio desse caminho podem surgir opções melhores, até então desconhecidas e que, às vezes, vale a pena trocá-las. E, por fim, se um programador tiver uma boa ideia, entretanto não estiver mais trabalhando nela, deve entregá-la para que outra pessoa a finalize.
O papel dos usuários e codesenvolvedores
No terceiro e quarto capítulo Raymond afirma que, quando herdou o programa para reestruturá-lo, também recebeu seus usuários. E isso, para o autor, é uma ótima forma de melhorar um código, principalmente quando essas pessoas também são hackers. É possível, então, deixar o código aberto, porque essas comunidades de desenvolvedores ajudam a depurar e resolver problemas mais rapidamente que uma equipe limitada o faria.
Ele apresenta mais três lições:
- Tratar seus usuários como codesenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz.
- Libere cedo. Libere frequentemente. E ouça seus fregueses.
- Dada uma base grande o suficiente de beta-testers e codesenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém.
De forma geral, ele reformula a concepção do que é um problema em um código. Ou seja, quando um programa é controlado por um número limitado de desenvolvedores que liberam versões a cada ano, por exemplo, os problemas geralmente são profundos e difíceis de solucionar. Mas, se por outro lado, forem disponibilizadas versões do códigos mais rapidamente, os problemas tornam-se triviais, pois com comunidades de desenvolvedores, alguém com uma ferramenta diversificada e um novo ponto de vista, terá outra forma de resolvê-los. Assim, os problemas se simplificam, tornando-se triviais.
Todas essas lições que o autor apresenta se baseiam na sua análise da criação do Linux. Para entender profundamente, leia o artigo completo (que, desde sua primeira publicação, em 1997, já passou por diversas mudanças – graças à licença de publicação aberta). E, para saber mais sobre software livre e código aberto, entre outros assuntos relacionados à tecnologia, participe do Latinoware 2022! No próximo post será apresentado o resto do resumo sobre o artigo “A catedral e o bazar” de Eric Raymond.
