A Catedral e o bazar – um pouco sobre Software Livre

A Catedral e o bazar – um pouco sobre Software Livre

(The Cathedral and the Bazaar)
por Eric S. Raymond


Cópia e redistribuição permitida sem royalty contanto que esta notificação esteja preservada. Traduzido por Erik Kohler – ekohler at programmer.net


Data: 1998/11/12 04:01:20

Eu analiso um projeto bem sucedido de código livre, o Fetchmail, que foi executado como um
teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programação
sugerida pela história do Linux. Eu discuto estas teorias nos termos de dois estilos
fundamentais diferentes de desenvolvimento, o modelo “catedral” da maior parte do mundo
comercial contra o modelo “bazar” do mundo do Linux. Eu mostro que estes modelos derivam
de suposições opostas sobre a natureza da tarefa de depurar o software. Eu faço então um
argumento sustentado na experiência do Linux para a proposição que “Dados bastante olhos,
todos os erros são triviais”, sugiro analogias produtivas com outros sistemas auto-corrigíveis
de agentes egoístas, e concluo com alguma exploração das implicações desta introspeção
para o futuro do software.

Eu analiso um projeto bem sucedido de código livre, o Fetchmail, que foi executado como um
teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programação
sugerida pela história do Linux. Eu discuto estas teorias nos termos de dois estilos
fundamentais diferentes de desenvolvimento, o modelo “catedral” da maior parte do mundo
comercial contra o modelo “bazar” do mundo do Linux. Eu mostro que estes modelos derivam
de suposições opostas sobre a natureza da tarefa de depurar o software. Eu faço então um
argumento sustentado na experiência do Linux para a proposição que “Dados bastante olhos,
todos os erros são triviais”, sugiro analogias produtivas com outros sistemas auto-corrigíveis
de agentes egoístas, e concluo com alguma exploração das implicações desta introspeção
para o futuro do software.

A Catedral e o Bazar Linux é subversivo.

Quem pensaria mesmo há cinco anos atrás que um sistema operacional de classe mundial
poderia surgir como que por mágica pelo tempo livre de milhares de colaboradores espalhados
por todo o planeta, conectado somente pelos tênues cordões da Internet? Certamente não eu.
No tempo que o Linux apareceu em minha tela-radar no início de 1993, eu já tinha me
envolvido no desenvolvimento de Unix e de código aberto por dez anos. Eu fui um dos
primeiros contribuintes para o projeto GNU nos meados de 1980. Eu tinha liberado bastante do
software livre na rede, desenvolvendo ou co-desenvolvendo diversos programas (nethack,
Emacs em modo VC e GUD, xlife, e outros) que estão ainda em largo uso hoje. Eu pensei que
eu sabia como isso era feito. Linux ultrapassou muito o que eu pensei que sabia. Eu estava
pregando o modo Unix de uso de pequenas ferramentas, de prototipagem rápida e de
programação evolucionária por anos. Mas eu acreditei também que havia alguma
complexidade crítica, acima da qual uma aproximação mais centralizada, mais a priori era
requerida. Eu acreditava que os softwares mais importantes (sistemas operacionais e
ferramentas realmente grandes como Emacs) necessitavam ser construídos como as
catedrais, habilmente criados com cuidado por mágicos ou pequenos grupos de magos
trabalhando em esplêndido isolamento, com nenhum beta para ser liberado antes de seu
tempo. O estilo de Linus Torvalds de desenvolvimento — libere cedo e freqüentemente,
delegue tudo que você possa, esteja aberto ao ponto da promiscuidade — veio como uma
surpresa. Nenhuma catedral calma e respeitosa aqui — ao invés, a comunidade Linux pareceu
assemelhar-se a um grande e barulhento bazar de diferentes agendas e aproximações
(adequadamente simbolizada pelos repositórios do Linux, que aceitaria submissões de
qualquer pessoa) de onde um sistema coerente e estável poderia aparentemente emergir
somente por uma sucessão de milagres. O fato de que este estilo bazar pareceu funcionar, e
funcionar bem, veio como um distinto choque. Conforme eu aprendia ao meu redor, trabalhei
duramente não apenas em projetos individuais, mas também tentando compreender porque o
mundo do Linux não somente não se dividiu em confusão mas parecia aumentar a sua força a
uma velocidade quase inacreditável para os construtores de catedrais. Em meados de 1996 eu
pensei que eu estava começando a compreender. O acaso deu-me uma maneira perfeita para
testar minha teoria, na forma de um projeto de código aberto que eu poderia conscientemente
tentar executar no estilo bazar. Assim eu fiz — e foi um sucesso significativo. No resto deste
artigo eu contarei a história desse projeto, e eu irei usá-la para propor alguns aforismos sobre
o desenvolvimento eficaz de código aberto. Nem tudo eu aprendi primeiramente no mundo do
Linux, mas nós veremos como o mundo do Linux lhe dá um ponto particular. Se eu estiver
correto, eles o ajudarão a compreender exatamente o que é que faz a comunidade do Linux
ser uma fonte de software bom — e ajuda a você a se tornar mais produtivo.

O correio deve ser entregue desde 1993

Eu venho cuidando da parte técnica de um pequeno Provedor de Acesso Internet de acesso
gratuito chamado Chester County InterLink (CCIL) em West Chester, Pensilvânia (eu fui cofundador
do CCIL e escrevi nosso software multiusuário de BBS — você pode observá-lo
executando um telnet para locke.ccil.org. Hoje suporta quase três mil usuários em trinta
linhas.) O trabalho permitiu-me o acesso 24 horas por dia à rede através da linha de 56K do
CCIL — de fato, praticamente exigiu! Consequentemente, eu fiquei acostumado a acesso
instantâneo ao correio Internet. Por razões complicadas, era difícil fazer o SLIP funcionar entre
minha máquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, eu
achei incômodo ter que executar telnet periodicamente para o locke para verificar meu correio.
O que eu queria era que ele fosse enviado para o snark de modo que eu fosse notificado
quando uma mensagem chegasse e pudesse manuseá-lo usando todas as minhas
ferramentas locais. O simples reenvio do sendmail não funcionaria, porque minha máquina
local não está sempre na rede e não tem um IP estático. O que eu precisava era um programa
que pegasse meu correio através da conexão SLIP e o entregasse localmente. Eu sabia que
tais programas existiam, e que a maioria deles usava um protocolo de aplicação simples
chamado POP (Post Office Protocol). E, realmente, já havia um servidor POP3 incluído com
sistema operacional BSD/OS do locke. Eu precisava de um cliente POP3. Então eu procurei na
Internet e encontrei um. Na verdade, eu encontrei três ou quatro. Eu usei o pop-perl por algum
tempo, mas faltava o que parecia uma característica óbvia, a habilidade de alterar os
endereços no correio recebido para que as respostas fossem enviadas corretamente. O
problema era este: suponha que alguém chamado joe' no locke tenha me enviado uma mensagem. Se eu capturasse o correio para o snark e tentasse então lhe responder, meu programa de correio tentaria alegremente enviá-lo a um joe’ inexistente no snark. Editar
manualmente os endereços de resposta para adicionar ‘@ccil.org’ rapidamente tornou-se um
tormento. Isto era claramente algo que o computador teria que fazer para mim. Mas nenhum
dos clientes POP existentes sabiam como! E isto nos traz à primeira lição: 1. Todo bom
trabalho de software começa colocando o dedo na ferida de um programador.
Talvez isto
deveria ter sido óbvio (um antigo provérbio diz que “necessidade é a mãe da invenção”) mas
muitas vezes os programadores gastam seus dias buscando retorno em programas que eles
não necessitam nem gostam. Mas não no mundo do Linux — o que pode explicar porque a
qualidade média do software originada na comunidade de Linux é tão alta. Assim, eu me lancei
imediatamente com o ímpeto de codificar um novo cliente POP3 para competir com os
existentes? De maneira alguma! Eu olhei com cuidado os utilitários POP que eu tinha à
disposição, perguntando-me “qual deles é o mais próximo do que eu quero?”. Porque… 2. Os
programadores bons sabem o que escrever. O grandes sabem o que re-escrever (e reusar).

Embora eu não me considere um grande programador, eu tento me passar por um.
Uma importante característica dos grandes é a preguiça construtiva. Eles sabem que você
ganha um ‘A’ não por esforço, mas por resultados, e é quase sempre mais fácil partir de uma
boa solução parcial do que do nada. não tentou realmente escrever Linux do nada. Ao
contrário, ele começou re-usando código e idéias do Minix, um pequeno sistema operacional
Unix-like para máquinas 386. Eventualmente todo o código Minix se foi ou não completamente
rescrito — mas quando estava lá, forneceu as bases para o infante que se transformaria no
Linux. Com o mesmo pensamento, eu fui procurar um utilitário POP que fosse razoavelmente
bem codificado, para usar como uma base de desenvolvimento. A tradição do mundo Unix de
compartilhar o código fonte foi sempre amigável para a reutilização de código (esta é a razão
porque o projeto de GNU escolheu o Unix como sistema operacional base, apesar das sérias
reservas sobre o mesmo). O mundo Linux tem levado esta tradição quase a seu limite
tecnológico; tem terabytes de códigos abertos amplamente disponíveis. Assim gastando tempo
procurando algum software quase-bom-o-bastante feito por alguém é mais provável dar a você
mais bons resultados no mundo Linux do que em qualquer outro lugar. Algumas semanas
mais tarde, entretanto, eu tropecei pelo código do ‘popclient’ desenvolvido por Carl Harris, e
descobri que eu tinha um problema. Embora o fetchpop tenha tido algumas idéias boas e
originais (tal como o modo daemon), podia somente trabalhar com POP3 e foi codificado de
uma maneira um tanto amadora (Seung-Hong era um programador brilhante porém
inexperiente, e ambas as características ficaram evidentes). O código de Carl era melhor,
bastante profissional e sólido, mas em seu programa faltou diversas características
importantes e complicadas de serem implementadas do fetchpop (incluindo aquelas que eu
implementei). Ficar ou trocar? Se eu trocasse, eu estaria jogando fora o código que eu já havia
feito em troca de uma base melhor do desenvolvimento. Um motivo prático para trocar era a
presença de suporte para vários protocolos. POP3 é o protocolo mais comumente utilizado de
todos os protocolos de correio dos servidores, mas não o único. Fetchpop e os outros
concorrentes não faziam POP2, RPOP ou APOP, e eu estava realmente tendo alguns
pensamentos de talvez adicionar ou Protocolo de Acesso a Mensagem da Internet, o mais
recente e poderoso protocolo de correio desenvolvido) só para me divertir. Mas eu tinha uma
razão mais teórica para pensar que trocar seria uma boa idéia, alguma coisa que eu aprendi
muito antes do Linux. 3. “Planeje jogar algo fora; você irá, de qualquer maneira.” (Fred
Brooks, “The Mythical Man-Month”, Capítulo 11)
Ou, colocando de outra forma, você
freqüentemente não entende realmente o problema até depois da primeira vez que você
implementa uma solução. Na segunda vez, talvez você saiba o suficiente para fazer
corretamente. Então se você quer fazer algo certo, esteja preparado para começar tudo
novamente pelo menos uma vez. Bem (eu disse para mim mesmo) as mudanças no fetchpop
foram a minha primeira tentativa. Então eu troquei. Depois que eu mandei meu primeiro
conjunto de alterações para Carl Harris em 25 de junho de 1996, eu percebi que na verdade
ele perdera o interesse pelo popclient há algum tempo até então. O código era um pouco
empoeirado, com pequenos erros. Eu tinha muitas mudanças para fazer, e nós rapidamente
concordamos que o lógico para eu fazer era tomar conta do programa. Sem perceber, o
projeto havia se intensificado. Eu não estava mais contemplando somente pequenos consertos
para um cliente POP existente. Eu estava mantendo um cliente completo, e havia idéias
borbulhando na minha cabeça que eu sabia iriam provavelmente levar a importantes
mudanças. Em uma cultura de software que encoraja a troca de código, isto é um caminho
natural para um projeto evoluir. Eu estava representando isto: 4. Se você tem a atitude certa,
problemas interessantes irão encontrá-lo. Mas a atitude do Carl Harris foi ainda mais
importante. Ele entendeu que 5. Quando você perde interesse em um programa, sua
última obrigação a fazer com ele é entregá-lo a um sucessor competente. Sem ao menos
ter que discutir isso, Carl e eu sabíamos que nós tínhamos um objetivo em comum de ter a
melhor solução disponível. A única questão para nós foi se eu poderia me estabelecer como
um par de mãos seguras para isso. Uma vez que eu tenha feito isso, ele agiu com cortesia e
rapidez. Eu espero que eu aja assim quando chegar a minha vez.

Richard Valdivia

Richard Valdivia

Mestre pela Universidade Federal de São Paulo (UNIFESP). É editor e redator desde 2014 de diversos canais na internet. Entusiasta de novas tecnologias, mídias sociais e empreendedor digital. Nômade Digital na prática, está sempre em busca de novos desafios, como programar para plataformas emergentes.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *