A CATEDRAL E O BAZAR

(The Cathedral and the Bazaar)

por Eric S. Raymond
Cpia e redistribuio permitida sem royalty contanto que esta notificao esteja preservada.
Traduzido por Erik Kohler - ekohler at programmer.net
Data: 1998/11/12 04:01:20
Eu analiso um projeto bem sucedido de cdigo livre, o Fetchmail, que foi executado como um
teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programao
sugerida pela histria 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 suposies opostas sobre a natureza da tarefa de depurar o software. Eu fao ento um
argumento sustentado na experincia do Linux para a proposio que "Dados bastante olhos,
todos os erros so triviais'', sugiro analogias produtivas com outros sistemas auto-corrigveis
de agentes egostas, e concluo com alguma explorao das implicaes desta introspeo
para o futuro do software.
1. A Catedral e o Bazar Linux subversivo.
Quem pensaria mesmo h cinco anos atrs que um sistema operacional de classe mundial
poderia surgir como que por mgica pelo tempo livre de milhares de colaboradores espalhados
por todo o planeta, conectado somente pelos tnues cordes da Internet? Certamente no eu.
No tempo que o Linux apareceu em minha tela-radar no incio de 1993, eu j tinha me
envolvido no desenvolvimento de Unix e de cdigo 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 esto 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 rpida e de
programao evolucionria por anos. Mas eu acreditei tambm que havia alguma
complexidade crtica, acima da qual uma aproximao mais centralizada, mais a priori era
requerida. Eu acreditava que os softwares mais importantes (sistemas operacionais e
ferramentas realmente grandes como Emacs) necessitavam ser construdos como as
catedrais, habilmente criados com cuidado por mgicos ou pequenos grupos de magos
trabalhando em esplndido isolamento, com nenhum beta para ser liberado antes de seu
tempo. O estilo de Linus Torvalds de desenvolvimento -- libere cedo e freqentemente,
delegue tudo que voc possa, esteja aberto ao ponto da promiscuidade -- veio como uma
surpresa. Nenhuma catedral calma e respeitosa aqui -- ao invs, a comunidade Linux pareceu
assemelhar-se a um grande e barulhento bazar de diferentes agendas e aproximaes
(adequadamente simbolizada pelos repositrios do Linux, que aceitaria submisses de
qualquer pessoa) de onde um sistema coerente e estvel poderia aparentemente emergir
somente por uma sucesso 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 no apenas em projetos individuais, mas tambm tentando compreender porque o
mundo do Linux no somente no se dividiu em confuso mas parecia aumentar a sua fora a
uma velocidade quase inacreditvel para os construtores de catedrais. Em meados de 1996 eu
pensei que eu estava comeando a compreender. O acaso deu-me uma maneira perfeita para
testar minha teoria, na forma de um projeto de cdigo 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 histria desse projeto, e eu irei us-la para propor alguns aforismos sobre
o desenvolvimento eficaz de cdigo aberto. Nem tudo eu aprendi primeiramente no mundo do

Linux, mas ns veremos como o mundo do Linux lhe d um ponto particular. Se eu estiver
correto, eles o ajudaro 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.
2. O correio deve ser entregue desde 1993
Eu venho cuidando da parte tcnica de um pequeno Provedor de Acesso Internet de acesso
gratuito chamado Chester County InterLink (CCIL) em West Chester, Pensilvnia (eu fui cofundador do CCIL e escrevi nosso software multiusurio de BBS -- voc pode observ-lo
executando um telnet para locke.ccil.org. Hoje suporta quase trs mil usurios em trinta
linhas.) O trabalho permitiu-me o acesso 24 horas por dia rede atravs da linha de 56K do
CCIL -- de fato, praticamente exigiu! Consequentemente, eu fiquei acostumado a acesso
instantneo ao correio Internet. Por razes complicadas, era difcil fazer o SLIP funcionar entre
minha mquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, eu
achei incmodo 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 no funcionaria, porque minha mquina
local no est sempre na rede e no tem um IP esttico. O que eu precisava era um programa
que pegasse meu correio atravs da conexo SLIP e o entregasse localmente. Eu sabia que
tais programas existiam, e que a maioria deles usava um protocolo de aplicao simples
chamado POP (Post Office Protocol). E, realmente, j havia um servidor POP3 includo com
sistema operacional BSD/OS do locke. Eu precisava de um cliente POP3. Ento eu procurei na
Internet e encontrei um. Na verdade, eu encontrei trs ou quatro. Eu usei o pop-perl por algum
tempo, mas faltava o que parecia uma caracterstica bvia, a habilidade de alterar os
endereos no correio recebido para que as respostas fossem enviadas corretamente. O
problema era este: suponha que algum chamado `joe' no locke tenha me enviado uma
mensagem. Se eu capturasse o correio para o snark e tentasse ento lhe responder, meu
programa de correio tentaria alegremente envi-lo a um `joe' inexistente no snark. Editar
manualmente os endereos 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 lio: 1. Todo bom
trabalho de software comea colocando o dedo na ferida de um programador. Talvez isto
deveria ter sido bvio (um antigo provrbio diz que "necessidade a me da inveno'') mas
muitas vezes os programadores gastam seus dias buscando retorno em programas que eles
no necessitam nem gostam. Mas no no mundo do Linux -- o que pode explicar porque a
qualidade mdia do software originada na comunidade de Linux to 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 utilitrios POP que eu tinha
disposio, perguntando-me "qual deles o mais prximo do que eu quero?''. Porque... 2. Os
programadores bons sabem o que escrever. O grandes sabem o que re-escrever (e reusar). Embora eu no me considere um grande programador, eu tento me passar por um.
Uma importante caracterstica dos grandes a preguia construtiva. Eles sabem que voc
ganha um 'A' no por esforo, mas por resultados, e quase sempre mais fcil partir de uma
boa soluo parcial do que do nada. no tentou realmente escrever Linux do nada. Ao
contrrio, ele comeou re-usando cdigo e idias do Minix, um pequeno sistema operacional
Unix-like para mquinas 386. Eventualmente todo o cdigo Minix se foi ou no 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 utilitrio POP que fosse razoavelmente
bem codificado, para usar como uma base de desenvolvimento. A tradio do mundo Unix de
compartilhar o cdigo fonte foi sempre amigvel para a reutilizao de cdigo (esta a razo
porque o projeto de GNU escolheu o Unix como sistema operacional base, apesar das srias
reservas sobre o mesmo). O mundo Linux tem levado esta tradio quase a seu limite
tecnolgico; tem terabytes de cdigos abertos amplamente disponveis. Assim gastando tempo
procurando algum software quase-bom-o-bastante feito por algum mais provvel dar a voc
mais bons resultados no mundo Linux do que em qualquer outro lugar. Algumas semanas
mais tarde, entretanto, eu tropecei pelo cdigo do 'popclient' desenvolvido por Carl Harris, e
descobri que eu tinha um problema. Embora o fetchpop tenha tido algumas idias 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 porm
inexperiente, e ambas as caractersticas ficaram evidentes). O cdigo de Carl era melhor,
bastante profissional e slido, mas em seu programa faltou diversas caractersticas
importantes e complicadas de serem implementadas do fetchpop (incluindo aquelas que eu
implementei). Ficar ou trocar? Se eu trocasse, eu estaria jogando fora o cdigo que eu j havia
feito em troca de uma base melhor do desenvolvimento. Um motivo prtico para trocar era a
presena de suporte para vrios protocolos. POP3 o protocolo mais comumente utilizado de
todos os protocolos de correio dos servidores, mas no o nico. Fetchpop e os outros
concorrentes no 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
razo mais terica para pensar que trocar seria uma boa idia, 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'', Captulo 11) Ou, colocando de outra forma, voc
freqentemente no entende realmente o problema at depois da primeira vez que voc
implementa uma soluo. Na segunda vez, talvez voc saiba o suficiente para fazer
corretamente. Ento se voc quer fazer algo certo, esteja preparado para comear tudo
novamente pelo menos uma vez. Bem (eu disse para mim mesmo) as mudanas no fetchpop
foram a minha primeira tentativa. Ento eu troquei. Depois que eu mandei meu primeiro
conjunto de alteraes para Carl Harris em 25 de junho de 1996, eu percebi que na verdade
ele perdera o interesse pelo popclient h algum tempo at ento. O cdigo era um pouco
empoeirado, com pequenos erros. Eu tinha muitas mudanas para fazer, e ns rapidamente
concordamos que o lgico para eu fazer era tomar conta do programa. Sem perceber, o
projeto havia se intensificado. Eu no estava mais contemplando somente pequenos consertos
para um cliente POP existente. Eu estava mantendo um cliente completo, e havia idias
borbulhando na minha cabea que eu sabia iriam provavelmente levar a importantes
mudanas. Em uma cultura de software que encoraja a troca de cdigo, isto um caminho
natural para um projeto evoluir. Eu estava representando isto: 4. Se voc tem a atitude certa,
problemas interessantes iro 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 obrigao a fazer com ele entreg-lo a um sucessor competente. Sem ao menos
ter que discutir isso, Carl e eu sabamos que ns tnhamos um objetivo em comum de ter a
melhor soluo disponvel. A nica questo para ns foi se eu poderia me estabelecer como
um par de mos 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.
3. A importncia de ter usurios
E ento eu herdei o popclient. To importante quanto, eu herdei os usurios do popclient.
Usurios so timas coisas para se ter, e no somente porque eles demonstram que voc est
satisfazendo uma necessidade, que voc fez algo certo. Cultivados de maneira adequada, eles
podem se tornar co-desenvolvedores. Outra fora da tradio do Unix, uma que o Linux tem
levado a um alegre extremo, que muitos usurios so desenvolvedores tambm. E porque o
cdigo fonte est disponvel, eles podem ser desenvolvedores eficazes. Isto pode ser
tremendamente til para reduzir o tempo de depurao. Com um pouco de estmulo, seus
usurios iro diagnosticar problemas, sugerir correes e ajudar a melhorar o cdigo muito
mais rapidamente do que voc poderia fazer sem ajuda. 6. Tratar seus usurios como codesenvolvedores seu caminho mais fcil para uma melhora do cdigo e depurao
eficaz. O poder deste efeito fcil de se subestimar. De fato, todos ns do mundo do cdigo
aberto subestimamos drasticamente como isto iria incrementar o nmero de usurios e
diminuir a complexidade do sistema, at que Linus Torvalds nos mostrou de outra forma. De
fato, eu penso que a engenhosidade do Linus e a maior parte do que desenvolveu no foram a
construo do kernel do Linux em si, mas sim a sua inveno do modelo de desenvolvimento
do Linux. Quando eu expressei esta opinio na sua presena uma vez, ele sorriu e
calmamente repetiu algo que freqentemente diz: "Sou basicamente uma pessoa muito
preguiosa que gosta de ganhar crdito por coisas que outras pessoas realmente fazem.''
Prequioso como uma raposa. Ou, como Robert Heinlein teria dito, muito preguioso para

falhar. Em retrospecto, um precedente para o sucesso e mtodos do Linux pode ser observado
no desenvolvimento da biblioteca do GNU Emacs Lisp e os repositrios de cdigo Lisp. Em
contraste com o estilo de desenvolvimento catedral do ncleo do Emacs C e a maioria das
outras ferramentas da FSF, a evoluo do grupo de cdigo Lisp foi fluda e bastante dirigida ao
usurio. Idias e prottipos foram freqentemente re-escritos trs ou quatro vezes antes de
atingirem uma forma estvel final. E colaboraes permitidas pela Internet, a la Linux, foram
freqentes. Realmente, minha mais bem sucedida codificao anterior ao fetchmail foi
provavelmente o modo Emacs VC, uma colaborao do tipo do Linux por email com trs
outras pessoas, somente uma das eu conheci pessoalmente at hoje. Foi um front-end para
SCCS, RCS e posteriormente CVS pelo Emacs que oferecia operaes de controle de verso
"um toque''. Evoluiu de um pequeno e grosseiro modo sccs.el que algum havia escrito. E o
desenvolvimento do VC foi bem sucedido porque, ao contrrio do prprio Emacs, o cdigo do
Emacs Lisp poderia ir por geraes de lanamento/teste/aperfeioamento muito rapidamente.
4. Libere cedo, libere freqentemente
Liberaes novas e freqentes so uma parte crtica do modelo de desenvolvimento do Linux.
A maioria dos desenvolvedores (incluindo eu) costumava acreditar que esta era uma m
poltica para projetos maiores que os triviais, porque verses novas so quase por definio
cheias de erros e voc no quer acabar com a pacincia dos seus usurios. Esta crena
reforou o compromisso de todos com o estilo de desenvolvimento catedral. Se o principal
objetivo era o de usurios verem menos erros quanto possvel, por que ento voc iria
somente lanar um em cada seis meses (ou freqentemente menos), e trabalhar como um
cachorro depurando entre as liberaes. O ncleo do Emacs C foi desenvolvido desta forma. A
biblioteca Lisp, de fato, no foi -- porque havia repositrios Lisp ativos fora do controle da FSF,
aonde voc poderia ir para achar verses novas e em desenvolvimento, independentemente
do ciclo de liberao do Emacs. A mais importante destas, o repositrio elisp do Estado de
Ohio, antecipou o esprito e muitas das caractersticas dos atuais grandes repositrio de Linux.
Mas pouco de ns realmente pensou muito sobre o que estvamos fazendo, ou sobre o que a
existncia deste repositrio sugeriu sobre problemas no modelo de desenvolvimento catedral
da FSF. Eu fiz uma sria tentativa por volta de 1992 para ter bastante cdigo de Ohio
formalmente fundido na biblioteca oficial do Emacs Lisp. Encontrei problemas polticos e fui
muito mal sucedido. Mas um ano depois, visto que o Linux se tornou amplamente conhecido,
ficou claro que alguma coisa diferente e muito saudvel estava acontecendo. A poltica de
desenvolvimento aberta do Linus era exatamente o oposto do modelo de desenvolvimento
catedral. Os repositrios sunsite e tsx-11 estavam germinando, mltiplas distribuies estavam
surgindo. E tudo isto foi guiado por uma freqncia desconhecida de liberaes de ncleo de
sistemas. Linus estava tratando seus usurios como co-desenvolvedores na maneira mais
eficaz possvel: 7. Liberece cedo. Libere freqentemente. E oua seus fregueses. Isso no
era muito a inovao do Linus (algo como isso estava sendo a tradio do mundo Unix por um
longo tempo), mas em elevar isto at um grau de intensidade que alcanava a complexidade
do que ele estava desenvolvendo. Nestes primrdios tempos (por volta de 1991) no era
estranho para ele liberar um novo kernel mais de uma vez por dia! E, porque ele cultivava sua
base de co-desenvolvedores e incitava fortemente a Internet por colaborao como nenhum
outro, isto funcionou. Mas como isto funcionou? E era isto algo que eu poderia duplicar, ou era
algo que dependia da genialidade nica de Linus Torvalds? Eu no pensei assim.
Reconhecidamente, Linus um excelente desenvolvedor (quantos de ns poderia planejar um
kernel completo de um sistema operacional de qualidade de produo?). Mas o Linux no
representou nenhum salto conceitual impressionante a frente. Linus no (ou pelo menos,
ainda no) um gnio inovativo de projeto do estilo que, por exemplo, Richard Stallman ou
James Gosling (do NeWS e Java) so. Ao contrrio, para mim Linus parece ser um gnio da
engenharia, com um sexto sentido em evitar erros e desenvolvimentos que levem a um beco
sem sada e uma verdadeira habilidade para achar o caminho do menor esforo do ponto A ao
ponto B. De fato, todo o projeto do Linux exala esta qualidade e espelha a abordagem
conservadora e simplificada de planejamento do Linus. Ento, se liberaes rpidas e
influenciar a Internet a todo custo no foram acidentes mas partes integrantes da perspiccia
do gnio de engenharia do Linus para o caminho do menor esforo, o que ele estava
enfatizando? O que ele estava maquinando? Posto desta forma, a questo responde a si

mesma. Linus estava mantendo seus usurios/desenvolvedores constantemente estimulados

e recompensados -- estimulados pela perspectiva de estar tendo um pouco de ao
satisfatria do ego, recompensados pela viso do constante (at mesmo dirio) melhoramento
do seu trabalho. Linus estava diretamente direcionado a maximizar o nmero de pessoas-hora
dedicadas a depurao e ao desenvolvimento, mesmo com o possvel custo da instabilidade
no cdigo e extino da base de usurios se qualquer erro srio provasse ser intratvel. Linus
estava se comportando como se acreditasse em algo como isto: 8. Dada uma base grande o
suficiente de beta-testers e co-desenvolvedores, praticamente todo problema ser
caracterizado rapidamente e a soluo ser bvia para algum. Ou, menos formalmente,
"Dados olhos suficientes, todos os erros so triviais.'' Eu chamo isso de: "Lei de Linus''. Minha
formulao original foi que todo problema "ser transparente para algum''. Linus objetou que
a pessoa que entende e conserta o problema no necessariamente ou mesmo
freqentemente a pessoa que primeiro o caracterizou. "Algum acha o problema,'' ele diz, "e
uma outra pessoa o entende. E eu deixo registrado que achar isto o grande desafio.'' Mas o
ponto que ambas as coisas tendem a acontecer rapidamente. Aqui, eu penso, o centro da
diferena fundamental entre os estilos bazar e catedral. Na viso catedral de programao,
erros e problemas de desenvolvimento so difceis, insidiosos, um fenmeno profundo. Leva
meses de exame minucioso por poucas pessoas dedicadas para desenvolver confiana de que
voc se livrou de todos eles. Por conseguinte os longos intervalos de liberao, e o inevitvel
desapontamento quando as liberaes por tanto tempo esperadas no so perfeitas. Na viso
bazar, por outro lado, voc assume que erros so geralmente um fenmeno trivial -- ou, pelo
menos, eles se tornam triviais muito rapidamente quando expostos para centenas de vidos
co-desenvolvedores triturando cada nova liberao. Consequentemente voc libera
freqentemente para ter mais correes, e como um benfico efeito colateral voc tem menos
a perder se um erro ocasional aparece. E isto. o suficiente. Se a "Lei de Linus'' falsa,
ento qualquer sistema to complexo como o kernel do Linux, sendo programado por tantas
mos quantas programam o kernel do Linux, deveria a um certo ponto tido um colapso sob o
peso de interaes imprevisveis e erros "profundos'' no descobertos. Se isto verdade, por
outro lado, suficiente para explicar a relativa falta de erros do Linux. E talvez isso no deveria
ser uma surpresa, mesmo assim. Anos atrs, sociologistas descobriram que a opinio mdia
de uma massa de observadores especialistas (ou igualmente ignorantes) um indicador mais
seguro que o de um nico observador escolhido aleatoriamente. Eles chamaram isso de o
"efeito Delphi''. Parece que o que o Linus tem mostrado que isto se aplica at mesmo para
depurar um sistema operacional -- que o efeito Delphi pode suavizar a complexidade do
desenvolvimento at mesmo em nvel de complexidade do kernel de um sistema operacional.
Eu sou grato a Jeff Dutky por apontar que a lei de Linus pode ser refeita como "Depurar
paralelizvel''. Jeff observa que embora depurar requer que depuradores se comuniquem com
algum desenvolvedor coordenador, no requer coordenao significante entre depuradores.
Assim no cai vtima para a mesma complexidade quadrtica e custos de gerncia que faz ser
problemtico adicionar desenvolvedores. Na prtica, a perda terica de eficincia devido a
duplicao de trabalho por depuradores quase nunca parece ser um problema no mundo do
Linux. Um efeito da ``poltica libere cedo e freqentemente'' minimizar esta duplicao
propagando consertos rapidamente. Brooks at mesmo fez uma observao improvisada
relacionada observao de Jeff: "O custo total de manter um programa amplamente utilizado
tipicamente 40 porcento ou mais o custo de desenvolv-lo. Surpreendentemente este custo
muito afetado pelo nmero de usurios. Mais usurios acham mais erros.'' (minha nfase).
Mais usurios acham mais erros porque adicionar mais usurios adiciona mais maneiras
diferentes de testar o programa. Este efeito amplificado quando os usurios so codesenvolvedores. Cada um aborda a tarefa de caracterizao de erro com um conjunto
perceptivo ligeiramente diferente e ferramenta analtica, um ngulo diferente do problema. O
"efeito Delphi'' parece funcionar precisamente por causa desta variao. No contexto
especfico da depurao, a variao tambm tende a reduzir o feito da duplicao. Ento
adicionar mais beta-testers pode no reduzir a complexidade de um erro "profundo'' corrente
do ponto de vista do desenvolvedor, mas aumenta a probabilidade que a ferramenta de
algum ir de encontro ao problema de uma maneira tal que o problema ser trivial para esta
pessoa. Linus cobre suas apostas. Caso haja erros srios, as verses do kernel do Linux so
numeradas de forma que usurios em potencial podem fazer a escolha de executar a ltima
verso designada "estvel'' ou correr o risco de encontrar erros para obter novas
caractersticas. Esta tcnica no ainda formalmente imitada pela maioria dos

desenvolvedores usurios do Linux, mas talvez devesse; o fato de que ambas as escolhas
estejam disponveis faz delas mais atraentes.
5. Quando uma rosa no uma rosa
Tendo estudado o comportamento do Linus e formado uma teoria sobre como ele foi bem
sucedido, eu fiz uma deciso 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 implementao do Carl Harris era muito
atrativa, mas exibia um tipo de complexidade desnecessria comum a vrios programadores
em C. Ele tratou o cdigo como centro das atenes e as estruturas de dados como suporte
para o cdigo. Como resultado, o cdigo era muito bonito mas o projeto da estrutura de dados
era ad-hoc e um tanto feio (pelo menos pelos altos padres deste velho desenvolvedor de
LISP). Eu tinha outro propsito para re-escrever alm de aperfeioar o cdigo e o projeto da
estrutura de dados, entretanto. Era evolu-lo para algo que eu entenderia completamente. No
nada agradvel ser responsvel por consertar erros em um programa que voc no entende.
Mais ou menos durante o primeiro ms, ento, eu estava simplesmente seguindo as
implicaes do projeto bsico do Carl. A primeira mudana sria que fiz foi adicionar suporte
ao IMAP. Eu fiz isso reorganizando as rotinas de protocolos em um driver genrico e trs
tabelas de mtodos (para POP2, POP3 e IMAP). Esta e as mudanas anteriores ilustram o
princpio geral que bom para os programadores manterem em mente, especialmente em
linguagens como C que no implementam naturalmente tipagem dinmica: 9. Estrutura de
dados inteligentes e cdigo burro trabalham muito melhor que ao contrrio. Brooks,
Captulo 11: "Mostre-me seu cdigo e esconda suas estruturas de dados, e eu poderei
continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente no
necessitarei do seu cdigo; ele ser bvio.'' De fato, ele disse "grficos'' e "tabelas''. Mas
considerando trinta anos de terminologias/mudanas culturais, praticamente o mesmo ponto.
Neste ponto (quase Setembro de 1996, mais ou menos seis semanas desde o incio) eu
comecei a pensar que uma mudana de nome deveria ser adequada -- afinal de contas, no
era mais somente um cliente POP. Mas eu hesitei, porque ainda no havia ainda nada
genuinamente novo ainda no projeto. Minha verso do popclient ainda teria que desenvolver
uma identidade prpria. 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 freqentemente (quase nunca menos que uma vez a cada dez dias; durante perodos
de desenvolvimento intenso, uma vez por dia). 2.Eu aumentei minha lista de beta testers
adicionando a ela todo mundo que me contatava sobre o fetchmail. 3.Eu mandei extensos
anncios lista de beta testers toda vez que eu liberava, encorajando as pessoas a participar.
4.E eu ouvia meus beta testers, questionando-os sobre decises de desenvolvimento e
incitando-os toda vez que eles mandavam consertos e respostas. O retorno destas medidas
simples foi imediato. Desde o incio do projeto, eu obtive relatrios sobre erros de uma
qualidade que a maioria dos desenvolvedores morreria para ter, muitas vezes com timos
consertos includos. Eu obtive crticas severas, obtive mensagens de fs, obtive sugestes
inteligentes de caractersticas. O que leva a: 10. Se voc tratar seus beta testers como seu
recurso mais valioso, eles iro 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 possua 249 membros e so adicionados dois
ou trs por semana. De fato, conforme eu reviso ao final de Maio de 1997, a lista est
comeando a perder membros depois do pico de aproximadamente 300 pessoas por uma
razo interessante. Muitas pessoas tm me pedido para exclu-las da lista porque o fetchmail
est trabalhando to bem para elas que elas no precisam mais ver o trfego da lista! Talvez
isto seja parte do ciclo de vida normal de um projeto maduro do estilo bazar.
6. Popclient transforma-se em Fetchmail
O verdadeiro ponto de mudana no projeto foi quando Harry Hochheiser me mandou o seu

rascunho de cdigo para reenviar mensagens para a porta SMTP da mquina cliente. Eu
percebi quase imediatamente que uma implementao segura desta caracterstica iria tornar
todos os outros modos de envio perto do obsoleto. Por muitas semanas eu fiquei
customizando o fetchmail de maneira incremental enquanto percebia como o projeto de
interface estava aproveitvel mas feio -- no estava elegante e com muitas pequenas opes
por toda parte. As opes para extrair mensagens coletadas para um arquivo de mensagens
ou sada padro particularmente me aborreciam, mas eu no conseguia descobrir por que. O
que eu vi quando eu pensei sobre reenvio SMTP foi que o popclient estava tentando fazer
muitas coisas. Ele foi projetado para ser tanto um agente transportador de correspondncia
(MTA) quanto um agente local de entrega (MDA). Com reenvio SMTP, ele poderia retirar o
MDA e ser somente um MTA, transferindo as correspondncias para outros programas para
entrega local como o sendmail faz. Por que se envolver com toda a complexidade de
configurar um agente de entrega de correspondncia ou configurar lock-e-append em um
arquivo de correio quando a porta 25 quase garantida para estar l em primeiro lugar em
qualquer plataforma com suporte para TCP/IP? Especialmente quando isso significa que o
correio coletado garantido parecer como um correio SMTP iniciado pelo remetente
normalmente, o que, de qualquer maneira, realmente o que queremos. H vrias lies aqui.
Primeira, esta idia de reenvio por SMTP foi o primeiro grande retorno que eu obtive por tentar
conscientemente emular os mtodos do Linus. Um usurio me deu esta idia brilhante -- tudo
que eu tive que fazer foi entender as implicaes. 11. A melhor coisa depois de ter boas
idias reconhecer boas idias dos seus usurios. As vezes a ltima melhor. E o que
interessante, voc ir rapidamente descobrir que se voc est se achando completamente
desacreditado sobre o quanto voc deve a outras pessoas, o mundo inteiro ir trat-lo como se
voc mesmo tivesse criado cada bit da inveno e est somente sendo modesto sobre seu
gnio inato. Ns todos podemos ver o quanto isso funcionou para Linus! (Quando eu mostrei
este documento na conferncia de Perl em Agosto de 1997, Larry Wall estava na primeira fila.
Quando eu li a ltima linha acima ele gritou fervorosamente, em um estilo religioso nostlgico,
"Diga, diga, irmo!''. Toda a audincia riu, porque eles sabiam que isso tambm funcionou para
o criador do Perl.) Aps poucas semanas executando o projeto no mesmo esprito, eu comecei
a ganhar um louvor semelhante no apenas dos meus usurios mas de outras pessoas que
deixaram as palavras escaparem. Eu guardei algumas destas mensagens; irei olhar para elas
novamente algum dia se eu comear a questionar se a minha vida valeu a pena :-). Mas h
duas lies mais fundamentais aqui, no polticas, que so gerais para todos os tipos de
projeto. 12. Freqentemente, as solues mais impressionantes e inovadoras surgem ao
se perceber que o seu conceito do problema estava errado. Eu estava tentando resolver o
problema errado ao desenvolver continuamente o popclient como um MTA/MDA combinado
com todos os tipos de modos de distribuio local. O projeto do fetchmail precisava ser
repensado do incio como um puro MTA, uma parte do caminho normal do correio da Internet
que fala SMTP. Quando voc atinge uma parede ao desenvolver -- quando voc dificilmente
se encontra pensando em algo depois do prximo patch -- freqentemente tempo para
perguntar no se voc tem a resposta certa, mas se voc est perguntando a pergunta
correta. Talvez o problema precise ser reformulado. Bem, eu reformulei meu problema.
Claramente, a coisa certa a fazer era (1) codificar o suporte para reenvio por SMTP no driver
genrico, (2) tornar isto o modo default, e (3) eventualmente desfazer todos os outros modos
de envio, especialmente as opes de enviar-para-arquivo e enviar-para-sada-padro. Eu
hesitei sobre o passo 3 por algum tempo, temendo aborrecer os usurios de longa data do
popclient dependentes dos mecanismos alternativos de envio. Em teoria, eles poderiam
imediatamente passar a usar arquivos .forward ou seus equivalentes no-sendmail para obter
os mesmos efeitos. Na prtica a transio poderia ser confusa. Mas quando eu a fiz, os
benefcios provaram-se altos. As partes obscuras do cdigo do driver sumiram. A configurao
ficou radicalmente mais simples -- no mais rastejar volta atrs do MDA do sistema e da
caixa de correio do usurio, no mais preocupaes sobre se o sistema operacional suportava
locking de arquivo. Alm disso, a nica maneira de perder correio sumira. Se voc especificava
envio para um arquivo e o disco estava cheio, seu correio estaria perdido. Isto no pode
acontecer com o reenvio por SMTP porque o receptor SMTP no retornar OK a no ser que a
mensagem possa ser enviada ou pelo menos reprogramada para um envio mais tarde. E
tambm, a performance aumentou (embora voc no perceberia isso somente com uma
execuo). Outro benefcio no insignificante foi que a pgina do manual ficou muito mais
simples. Mais tarde, eu tive que recolocar envio por um MDA local especificado pelo usurio

para permitir o tratamento de algumas situaes obscuras envolvendo SLIP dinmico. Mas eu
encontrei um_ maneira muito mais simples de fazer isto. A moral? No hesite em jogar fora
caractersticas obsoletas quando voc puder fazer isso sem perda de efetividade. Antoine de
Saint-Exupry (que foi um aviador e projetista de avies quando ele no estava sendo o autor
de livros clssicos infantis) disse: 13. "A perfeio (em projetar) alcanada no quando
no h mais nada a adicionar, mas quando no h nada para jogar fora.'' Quando o seu
cdigo est ficando to bom quanto simples, quando voc sabe que est correto. E no
processo, o projeto do fetchmail adquiriu uma identidade prpria, diferente do ancestral
popclient. Era tempo para a mudana de nome. O novo projeto parecia muito mais como um
irmo do sendmail do que o velho popclient parecia; ambos eram MTAs, mas aonde o
sendmail passa e ento envia, o novo popclient coleta e ento envia. Ento, aps 2 meses, eu
mudei o nome para fetchmail.
7. Fetchmail cresce
L estava eu com um projeto elegante e inovador, um cdigo que eu sabia que funcionava
bem porque eu usava todos os dias, e uma crescente lista de beta testers. E gradualmente eu
percebia que eu no estava mais ocupado com uma trivial codificao pessoal que porventura
poderia se tornar til para algumas pessoas. Eu tinha em minhas mos um programa que
todos os usurios de um sistema Unix com uma conexo de correio SLIP/PPP realmente
precisavam. Com a caracterstica de reenvio por SMTP, ele passou muito frente da
competio para potencialmente se tornar um "category killer'', um destes programas clssicos
que preenchem seu nicho to completamente que as alternativas no so somente
descartadas como tambm esquecidas. Eu penso que voc no pode realmente almejar ou
planejar um resultado como este. Voc tem que ser atrado para isso por idias de projeto to
poderosas que posteriormente os resultados parecem inevitveis, naturais, mesmo
predestinados. A nica maneira de tentar idias como esta tendo muitas idias -- ou tendo o
julgamento de engenharia para levar as boas idias das outras pessoas alm do que estas
que as tiveram pensariam que elas poderiam ir. Andrew Tanenbaum teve a idia original de
construir um Unix nativo simples para o 386, para uso como uma ferramenta de ensino. Linus
Torvalds levou o conceito do Minix para alm do que Andrew provavelmente pensou que
poderia ir -- e cresceu para algo maravilhoso. Da mesma forma (embora em uma menor
escala), eu peguei algumas idias de Carl Harris e Harry Hochheiser e dei um empurro.
Nenhum de ns foi 'original' no sentido romntico que as pessoas pensam um gnio. Mas a
maioria do desenvolvimento de software cientfico e de engenharia no feita por um gnio
original, a mitologia desenvolvedor ao contrrio. Os resultados foram todos sempre muito
precipitados -- de fato, o tipo de sucesso que qualquer desenvolvedor est sempre
procurando! E eles significaram que eu teria que definir meus padres ainda mais altos. Para
fazer o fetchmail to bom como eu ento achava que poderia se tornar, eu teria que escrever
no somente para minhas prprias necessidades, mas tambm incluir e suportar
caractersticas necessrias para outros fora do meu relacionamento. E fazer isto mantendo o
programa simples e robusto. A primeira e mais importante esmagadora caracterstica que eu
escrevi depois de perceber isto foi o suporte a multidrop -- a habilidade de capturar correio de
caixas de correio que acumularam todas as mensagens para um grupo de usurios, e ento
destinar cada pedao de correio para seus destinatrios individuais. Eu decidi adicionar o
suporte ao multidrop em parte porque alguns usurios estavam pedindo por isto, mas
principalmente porque eu pensei que isto iria retirar os erros do cdigo para o envio simples
me forando a manipular o endereamento de um modo geral. E assim se provou 822 me
tomou um tempo consideravelmente longo, no porque qualquer pedao dele difcil mas
porque envolvia uma pilha de detalhes interdependentes e elaborados. Mas o endereamento
multidrop se tornou uma deciso de projeto excelente. Aqui est como eu soube: 14. Qualquer
ferramenta deve ser til da maneira esperada, mas uma ferramenta verdadeiramente
*boa* leva ela prpria a usos que voc nunca esperou. Outra importante mudana
solicitada pelos meus beta testers foi suporte para operao MIME 8-bit. Isto foi muito fcil de
fazer, porque eu estava sendo cuidadoso mantendo o cdigo pronto para 8-bit. No porque eu
antecipei a demanda para esta caracterstica, mas em obedincia a outra regra: 15. Quando
escrevendo um software gateway de qualquer tipo, faa tudo para perturbar o conjunto
de dados o menos possvel -- e *nunca* jogue fora informao a no ser que o

destinatrio force voc a isto! Se eu no tivesse obedecido esta regra, o suporte a MIME 8bit teria sido difcil e cheio de erros. Como estava, tudo o que tive 1652 e adicionar um pouco
de lgica trivial para a gerao de cabealho. Alguns usurios Europeus insistiram para que eu
adicionasse uma opo para limitar o nmero de mensagens recebidas por seo (de maneira
que eles poderiam controlar custos das suas caras redes de telefone). Eu resisti por um longo
tempo, e ainda no estou inteiramente alegre sobre isto. Mas se voc est escrevendo para o
mundo, voc tem que ouvir os seus clientes -- isto no muda somente porque eles no esto
pagando dinheiro a voc.
8. Algumas lies a mais do Fetchmail
Antes de voltarmos ao assunto de engenharia de software em geral, existem algumas lies a
mais da experincia do fetchmail para ponderar. A sintaxe do arquivo rc inclui palavra-chaves
'ruidosas' opcionais que so inteiramente ignoradas pelo analisador. A sintaxe parecida com o
Ingls que elas permitem consideravelmente mais inteligvel que os concisos pares
tradicionais palavra-chave-valor que voc obtm quando as retira. Estas comearam como um
experimento posterior quando eu percebi como as declaraes do arquivo rc estava
comeando a lembrar uma mini-linguagem imperativa. ( por isto tambm que eu mudei a
palavra-chave original 'server' do popclient para 'poll'). Parecia para mim que tentar fazer esta
mini-linguagem imperativa parecer mais como o Ingls poderia torn-la mais fcil de ser usada.
Agora, embora eu seja um convencido adepto da escola de projeto "faa isso uma linguagem''
como exemplificado pelo Emacs e HTML e muitos sistemas de banco de dados, eu
normalmente no sou um grande f das sintaxes "English-like''. Programadores tradicionais
tendem a serem a favor de sintaxes de controle que so muito precisas e compactas e no
contm redundncia alguma. Isto um legado cultural de quando os recursos computacionais
eram caros, ento os estgios de anlise tinham que ser to baratos e simples quanto
possveis. O Ingls, com redundncia de aproximadamente 50%, parecia ser um modelo muito
imprprio. Esta no minha razo para normalmente evitar sintaxes no estilo do Ingls; eu
menciono isto aqui somente para arras-la. Com ciclos e ncleos baratos, conciso no deve
ser ela mesma um fim. Hoje em dia mais importante para uma linguagem ser conveniente
para humanos do que ser barata para o computador. H, entretanto, boas razes para ser
cauteloso. Uma o custo da complexidade do estgio de anlise -- voc no quer aument-lo
ao ponto onde uma fonte significativa de erros e confuso de usurios. Outra que tentar
fazer a sintaxe de uma linguagem English-like freqentemente demanda que o "Ingls'' que
falado seja seriamente propenso a ser fora de forma, tanto como a semelhana superficial com
a linguagem natural to confusa como a sintaxe tradicional seria. (Voc v isso em vrias
linguagens chamadas de "quarta gerao'' e em linguagens de consulta de banco de dados
comerciais.) A sintaxe de controle do fetchmail parece evitar estes problemas porque o
domnio da linguagem extremamente restrito. No perto de uma linguagem de uso geral;
as coisas que ela diz simplesmente no so muito complicadas, ento h pouco potencial para
confuso em mover mentalmente entre um pequeno conjunto do Ingls e a real linguagem de
controle. Eu acho que h uma lio mais abrangente aqui: 16. Quando sua linguagem no
est perto de um Turing completo, acar sinttico pode ser seu amigo. Outra lio
sobre segurana por obscuridade. Alguns usurios do fetchmail me pediram para mudar o
software para guardar as senhas encriptadas no arquivo rc, de maneira que bisbilhoteiros no
poderiam casualmente v-las. Eu no fiz isso, porque isto no adiciona realmente proteo.
Qualquer pessoa que adquira permisses para ler seu arquivo rc poder executar o fetchmail
como voc de qualquer maneira -- e se a sua senha o que eles procuram, poderiam retirar o
decodificador do prprio fetchmail para consegui-la. Tudo o que a encriptao de senha do
arquivo .fetchmailrc faria seria dar a falsa impresso de segurana para pessoas que no
pensaram bem sobre este assunto. Aqui a regra geral : 17. Um sistema de segurana to
seguro quanto secreto. Esteja atento a pseudo-segredos.
9. Pr-condies necessrias para o estilo Bazar
Os primeiros leitores e audincias para este documento seguidamente levantaram questes
sobre as pr-condies para o desenvolvimento bem-sucedido do estilo bazar, incluindo as

qualificaes do lder do projeto e o estado do cdigo ao tempo em que se torna pblico e

comea a tentar construir uma comunidade de co-desenvolvedores. Est claro que ningum
pode codificar desde o incio no estilo bazar. Algum pode testar, achar erros e aperfeioar no
estilo bazar, mas seria muito difcil originar um projeto no estilo bazar. Linus no tentou isto. Eu
tambm no. A sua comunidade nascente de desenvolvedores precisa ter algo executvel e
passvel de testes para utilizar. Quando voc comea a construo de uma comunidade, o que
voc precisa ter capacidade de apresentar uma promessa plausvel. Seu programa no
precisa funcionar particularmente bem. Ele pode ser grosseiro, cheio de erros, incompleto, e
pobremente documentado. O que no pode deixar de fazer convencer co-desenvolvedores
em potencial de que ele pode evoluir para algo realmente elegante em um futuro prximo.
Tanto o Linux quanto o fetchmail se tornaram pblicos com projetos bsicos fortes e atraentes.
Muitas pessoas pensando sobre o modelo bazar como eu tenho apresentado tm
corretamente considerado isto como crtico, ento concluram a partir disso que um alto grau
de intuio e inteligncia no lder do projeto indispensvel. Mas Linus obteve seu plano do
Unix. Eu obtive o meu inicialmente do ancestral do popclient (embora iria posteriormente
mudar bastante, muito mais proporcionalmente falando do que mudou o Linux). Ento
necessrio realmente para o lder/coordenador de um empenho no estilo bazar ter um talento
excepcional para planejamento, ou ele pode conseguir o mesmo efeito coordenando o talento
de planejamento de outras pessoas? Eu penso que no crtico que o coordenador seja
capaz de originar projetos de excepcional brilho, mas absolutamente crtico que o
coordenador seja capaz de reconhecer boas idias de projetos de outras pessoas. Tanto os
projetos do Linux quanto o do fetchmail mostram evidncias disso. Linus, no sendo (como
previamente discutido) um planejador espetacularmente original, mostrou uma habilidade
poderosa de reconhecer um bom projeto e integr-lo no kernel do Linux. E eu j descrevi como
a idia de projeto mais poderosa do fetchmail (reenvio por SMTP) veio de outra pessoa. Os
primeiros leitores deste documento me elogiaram sugerindo que eu sou propenso a subestimar
a originalidade do planejamento de projetos no estilo bazar porque eu tenho muito disso em
mim mesmo, e portanto suponho isto. Pode haver alguma verdade nisto; projetar (como oposto
a codificar ou depurar) certamente minha mais forte habilidade. Mas o problema em ser
inteligente e original no planejamento de software que isto se torna um hbito -- voc
comea reflexivamente a fazer coisas atraentes e complicadas quando voc deveria mant-las
robustas e simples. Eu tive projetos que falharam porque eu cometi este erro, mas eu
administrei para que no acontecesse o mesmo com o fetchmail. Ento eu acredito que o
projeto do fetchmail foi um sucesso em parte porque eu impedi a minha tendncia a ser
engenhoso; isto vai contra (pelo menos) com o fato de a originalidade em projetar ser
essencial para projetos bem-sucedidos no estilo bazar. E considere o Linux. Suponha que
Linus Torvalds estivesse tentando levar a cabo inovaes fundamentais no projeto de sistemas
operacionais durante o desenvolvimento; pareceria que o kernel resultante seria to estvel e
bem-sucedido como ? Um certo nvel bsico de habilidade de projetar e codificar requerido,
claro, mas eu suponho que praticamente qualquer um que pense seriamente em lanar um
esforo no estilo bazar estar acima do mnimo necessrio. O mercado interno da comunidade
de software aberto, por reputao, exerce uma sutil presso nas pessoas para que no lancem
esforo de desenvolvimento que no sejam competentes para manter. At agora isto parece
ter funcionado muito bem. H outro tipo de habilidade que no normalmente associada com
o desenvolvimento de software que eu penso to importante quanto a engenhosidade em
planejar projetos no estilo bazar -- e isto pode ser mais importante. Um coordenador ou lder
de um projeto no estilo bazar deve ter boa habilidade de comunicao e relacionamento. Isto
deve parecer bvio. Para construir uma comunidade de desenvolvimento, voc precisa atrair
pessoas, fazer com que se interessem no que voc est fazendo, e mant-las alegres sobre a
quantidade de trabalho que esto fazendo. O entusiasmo tcnico constitui uma boa parte para
atingir isto, mas est longe de ser toda histria. A personalidade que voc projeta tambm
importa. No uma coincidncia que Linus um rapaz gentil que faz com que as pessoas
gostem dele e que o ajudem. No uma coincidncia que eu seja um enrgico extrovertido
que gosta de trabalhar com pessoas e tenha um pouco de porte e instinto de um cmico. Para
fazer o modelo bazar funcionar, isto ajuda enormemente se voc tem pelo menos um pouco de
habilidade para encantar as pessoas.
10. O contexto social do cdigo aberto

Est escrito: os melhores programas comeam como solues pessoais para os problemas
dirios do autor, e se espalham porque o problema se torna tpico para uma grande classe de
usurios. Isto nos traz novamente para a regra 1, recolocada talvez de uma maneira mais til:
18. Para resolver um problema interessante, comece achando um problema que
interessante para voc. Isso foi o que aconteceu com Carl Harris e o ancestral popclient, e
tambm comigo e o fetchmail. Mas isso foi entendido por um longo tempo. O ponto
interessante, o ponto que as histrias do Linux e do fetchmail parecem demandar o nosso
foco, o prximo estgio -- a evoluo do software na presena de uma comunidade grande e
ativa de co-desenvolvedores. Em "The Mythical Man-Month'', Fred Brooks observou que o
tempo de um programador no acumulativo; adicionar desenvolvedores em um projeto
atrasado de software faz com que ele se torne mais atrasado. Ele exps que a complexidade e
custos de comunicao de um projeto crescem com o quadrado do nmero de
desenvolvedores, enquanto o trabalho feito cresce somente linearmente. Esta afirmao
desde ento conhecida como "A Lei de Brooks'' e largamente considerada como correta.
Mas se a Lei de Brooks fosse tudo a ser levado em considerao, o Linux seria impossvel. O
clssico "The Psychology Of Computer Programming'', de Gerald Weinberg, sustentou o que,
em retrospectiva, ns podemos ver como uma correo essencial ao Brooks. Em sua
discusso sobre "programao sem ego'', Weinberg observou que nos lugares onde
desenvolvedores no so territoriais sobre seu cdigo, e encorajam outras pessoas a procurar
por erros e melhorias potenciais nele, as melhorias acontecem dramaticamente mais rpidas
que em qualquer outro lugar. A escolha da terminologia de Weinberg talvez tenha prevenido
sua anlise de ganhar a aceitao que merecia -- engraado pensar em descrever os
desenvolvedores da Internet como "sem ego''. Mas acho que seu argumento parece mais mais
convincente hoje do que nunca. A histria do Unix deveria ter sido preparada para ns do que
ns estamos aprendendo com o Linux (e o que eu tenho verificado experimentalmente em
uma menor escala por copiar deliberadamente os mtodos do Linus). Isto , embora codificar
permanea uma atividade essencialmente solitria, os hacks realmente bons advm de captar
a ateno e poder de mente de comunidades inteiras. O desenvolvedor que utiliza apenas a
capacidade cerebral dele mesmo em um projeto fechado ir ficar atrs de desenvolvedores
que saibam como criar um contexto aberto e evolutivo no qual a visualizao de erros e
melhorias sejam feitas por centenas de pessoas. Mas o mundo tradicional do Unix foi impedido
de seguir completamente este mtodo por vrios fatores. Alguns deles foram os aspectos
legais de vrias licenas, segredos de comrcio e interesses comerciais. Outro (tardio) foi que
a Internet ainda no estava boa o suficiente. Antes de a Internet baratear, havia algumas
comunidades geograficamente pequenas aonde a cultura motivava a programao "sem
ego"??? de Weinberg, e aonde um desenvolvedor poderia facilmente atrair muitos codesenvolvedores habilidosos. Bell Labs, o MIT AI Lab, UC Berkeley -- estes se tornaram a
origem de inovaes que so lendrias e ainda fortes. Linux foi o primeiro projeto a fazer um
esforo consciente e bem-sucedido a utilizar o mundo inteiro como sua reserva de talentos. Eu
no acho que seja uma coincidncia que o perodo de gestao do Linux tenha coincidido com
o nascimento da World Wide Web, e que o Linux tenha deixado a sua infncia durante o
mesmo perodo em 1993-1994 que viu a expanso da indstria de ISP e a exploso do
principal interesse da Internet. Linus foi a primeira pessoa que aprendeu como jogar com as
novas regras que a onipresente Internet fez possvel. Embora uma Internet barata fosse uma
condio necessria para que o modelo do Linux evolusse, eu penso que no foi uma
condio por si s suficiente. Outro fator vital foi o desenvolvimento de um estilo de liderana e
conjunto de formalidades cooperativas que permitiria aos desenvolvedores atrair codesenvolvedores e obter o mximo suporte do ambiente. Mas o que este estilo de liderana
e estas formalidades? Eles no podem estar baseados em relaes de poder -- e mesmo que
pudessem, a liderana por coero no produziria os resultados que ns vemos. Weinberg cita
a autobiografia do anarquista do sculo 19 chamado Pyotr Alexeyvich Kropotkin, "Memrias de
um Revolucionista'' para demonstrar o efeito neste assunto: "Tendo sido criado em uma famlia
possuidora de vassalos, eu entrei a vida ativa, como todos os jovens homens da minha idade,
com uma grande confidncia na necessidade de comandar, ordenar, repreender, punir e etc.
Mas quando cedo tive que conduzir empreendimentos srios e lidar com homens [livres], e
quando cada erro levaria de uma vez a srias conseqncias, eu comecei a apreciar a
diferena entre atuar segundo o princpio de comando e disciplina e atuar segundo o princpio
da compreenso comum. O primeiro funciona de forma admirvel em uma parada militar, mas

de nada vale aonde a vida real considerada, e o objetivo pode ser atingido somente pelo
esforo severo de muitos propsitos convergentes.'' O "esforo severo de muitos propsitos
convergentes'' precisamente o que um projeto como o Linux requer -- e o "princpio de
comando'' efetivamente impossvel de ser aplicado entre voluntrios no paraso anarquista
que ns chamamos de Internet. Para operar e competir efetivamente, desenvolvedores que
querem liderar projetos colaborativos tm que aprender como recrutar e energizar
comunidades eficazes com interesse no modo vagamente sugerido pelo "princpio de
compreenso'' sugerido por Kropotkin. Eles precisam aprender a Lei de Linus. Inicialmente eu
me referi ao "Efeito Delphi'' como uma possvel explicao para a Lei de Linus. Porm
analogias mais poderosas aos sistemas adaptativos em biologia e economia tambm se
implicam fortemente. O mundo do Linux se comporta em vrios aspectos como um mercado
livre ou uma ecologia, uma coleo de agentes autnomos tentando maximizar um
empreendimento que no processo produz uma ordem espontnea auto-evolutiva mais
elaborada e eficiente que qualquer quantidade de planejamento central poderia ter alcanado.
Aqui, ento, o lugar para procurar o "princpio da compreenso''. A "funo empreendedora''
que os desenvolvedores do Linux esto maximizando no economia clssica, mas a
intangvel satisfao do seu prprio ego e reputao entre outros desenvolvedores. (Algum
pode chamar a sua motivao de "altrusta'', mas isso ignora o fato que altrusmo em si
mesmo uma forma de satisfao do ego para um altrusta). Culturas voluntrias que trabalham
desta maneira no so realmente incomuns; uma outra que eu tenho participado h tempos
os fs de fico cientfica, que ao contrrio dos desenvolvedores, explicitamente reconhecem o
"egoboo'' (o aumento da reputao de algum entre os outros fs) como o guia bsico por trs
da atividade voluntria. Linus, por posicionar ele mesmo como o guia de um projeto em que o
desenvolvimento praticamente feito por outros, e por inspirar interesse no projeto at que ele
se tornasse auto-sustentvel, tem mostrado um intenso entendimento do "princpio da
compreenso comum'' de Kropotkin. Esta viso quase-econmica do mundo do Linux nos
permite ver como esta compreenso aplicada. Ns podemos ver o mtodo do Linus como
uma maneira de criar um mercado eficiente no "egoboo'' -- para ligar a autonomia de
desenvolvedores individuais to firme quanto possvel para dificultar fins que podem ser
somente atingidos por uma cooperao sustentada. Com o projeto do fetchmail eu tenho
mostrado (embora em uma menor escala) que seus mtodos podem ser duplicados com bons
resultados. Talvez eu tenha at mesmo feito de uma maneira um pouco mais consciente e
sistemtica do que ele. Muitas pessoas (especialmente aquelas que politicamente
desacreditam os mercados livres) poderiam esperar de uma cultura de egostas autodirecionadores ser fragmentada, territorial, desperdiadora, reservada e hostil. Mas esta
expectativa claramente desfeita pela (para dar s um exemplo) imensa variedade, qualidade
e profundidade da documentao do Linux. notoriamente conhecido que os programadores
detestam documentar; como, ento, os desenvolvedores do Linux geram tanto disto?
Evidentemente o mercado livre do Linux em egoboo trabalha melhor para produzir
comportamentos virtuosos e direcionados a outros propsitos que os centros de
documentao massivamente fundados de produtores de software comercial. Tanto o projeto
do fetchmail como o do kernel do Linux mostram que ao se recompensar propriamente o ego
de muitos outros desenvolvedores, um desenvolvedor/coordenador forte pode usar a Internet
para capturar os benefcios de se ter vrios co-desenvolvedores sem fazer o projeto colapsar
em uma confuso catica. Ento eu contra-proponho para a Lei de Brooks o seguinte: 19.
Contanto que o coordenador do desenvolvimento tenha uma mdia pelo menos to boa
quanto a Internet, e saiba como liderar sem coero, muitas cabeas so
inevitavelmente melhores que uma. Eu acredito que o futuro do software de cdigo aberto
ir pertencer gradativamente a pessoas que saibam como jogar o jogo do Linus, pessoas que
deixam para trs a catedral e abraam o bazar. Isto no quer dizer que uma viso individual e
brilhante no ir mais ter importncia; ao contrrio, eu acredito que o estado da arte do
software de cdigo aberto ir pertencer a pessoas que iniciem de uma viso individual e
brilhante, ento amplificando-a atravs da construo efetiva de uma comunidade voluntria
de interesse. E talvez no somente o futuro do software de cdigo aberto. Nenhum
desenvolvedor de cdigo fechado pode competir com o conjunto de talento que a comunidade
do Linux pode dar para resolver um problema. Muito poucos podem at mesmo ser capazes
de pagar as mais de duzentas pessoas que tm contribudo para o fetchmail! Talvez no final a
cultura de cdigo aberto ir triunfar no porque a cooperao moralmente correta ou a
"proteo'' do software moralmente errada (assumindo que voc acredita na ltima, o que

no faz tanto o Linus como eu), mas simplesmente porque o mundo do software de cdigo
fechado no pode vencer uma corrida evolucionria com as comunidades de cdigo aberto
que podem colocar mais tempo hbil ordens de magnitude acima em um problema.
11. Agradecimentos
Este documento foi enriquecido atravs de conversas com um grande nmero de pessoas que
ajudaram a depur-lo. Agradecimentos particulares a Jeff Dutky , que sugeriu a formulao
"depurao paralelizvel'', e ajudou a desenvolver a anlise que se procedeu a isso. E
tambm a Nancy Lebovitz pela sua sugesto que eu imitei Weinberg ao citar Kropotkin.
Crticas incisivas tambm vieram de Joan Eslinger e Marty Franz da lista de Tcnicas Gerais.
Sou grato aos membros do PLUG, o Grupo de Usurios de Linux da Filadlfia, por permitir a
primeira audincia de teste para a primeira verso pblica deste documento. Finalmente, os
comentrios de Linus Torvalds foram importantes e seu apoio desde o incio foi muito
estimulante.
12. Para leitura adicional
Eu citei vrias frases do clssico The Mythical Man-Month de Frederick P. Brook porque, em
muitos aspectos, suas consideraes ainda precisam ser mais analisadas. Eu recomendo
fortemente a 25a. edio de Aniversrio de Addison-Wesley (ISBN 0-201-83595-9), que
adiciona seu documento "No Silver Bullet'' de 1986. A nova edio envolvida por uma
inestimvel retrospectiva de 20 anos atrasada na qual Brooks admite francamente os poucos
julgamentos no texto original que no resistiram ao teste do tempo. Achei que a retrospectiva
deste documento estava substancialmente completa, e fiquei surpreso ao descobrir que
Brooks atribui prticas como o estilo bazar Microsoft! (De fato, entretanto, esta atribuio
Halloween que a comunidade interna de desenvolvimento da Microsoft estratificada, com o
tipo comum de acesso ao cdigo necessrio para suportar o bazar muitas vezes nem mesmo
possvel.) The Psychology Of Computer Programming, de Gerald M. Weinberg (New York, Van
Nostrand Reinhold 1971) introduziu o conceito um tanto mal nomeado de "programao sem
ego''. Embora ele no estivesse nem perto de ser a primeira pessoa a perceber a futilidade do
"princpio do comando'', ele foi provavelmente o primeiro a reconhecer e argumentar o ponto
particular de ligao com o desenvolvimento de software. Richard P. Gabriel, contemplando a
cultura Unix da era pr-Linux, relutantemente argumentou a favor da superioridade do modelo
primitivo do estilo bazar em seu documento Lisp: Good News, Bad News, and How To Win Big,
de 1989. Embora obsoleto em alguns aspectos, este ensaio ainda muito cotado entre os fs
do Lisp (incluindo eu). Um correspondente me lembrou que a seo entitulada "O Pior o
Melhor'' parece-se mais como uma antecipao do Peopleware: Productive Projects and
Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6), de De Marco e Lister, uma
jia pouco apreciada na qual fiquei deliciado em ver Fred Brooks cit-la em sua retrospectiva.
Embora pouco do que os autores tm a dizer diretamente aplicvel s comunidades do
cdigo aberto do Linux, as idias do autor sobre as condies necessrias para um trabalho
criativo incisivo e vlido para qualquer um que tente importar um pouco das virtudes do
modelo bazar para o contexto comercial. Finalmente, eu devo admitir que eu quase chamei
este documento de "A Catedral e a gora'', o ltimo termo sendo o grego para um mercado
aberto ou um lugar de encontro pblico. Os documentos "sistemas agricos'' de Mark Miller e
Eric Drexler, descrevendo as propriedades emergentes de ecologias computacionais de
mercado, me ajudaram a me preparar a pensar claramente sobre fenmenos anlogos na
cultura do cdigo aberto quando o Linux esfregou o meu nariz neles cinco anos
13. Eplogo: Netscape acata o Bazar!
um sentimento estranho perceber que voc est ajudando a fazer histria? Em 22 de
Janeiro de 1998, aproximadamente sete meses depois que eu publiquei pela primeira vez este
documento, Netscape Communications, Inc. anunciou o cdigo aberto do Netscape
Communicator.

14. Verso e Histrico de Mudanas

$Id: cathedral-bazaar.sgml,v 1.42 1998/11/22 04:01:20 esr Exp $
Eu liberei a verso 1.16 no Linux Kongress, em 21 de Maio de 1997.
Eu adicionei a bibliografia em 7 de Julho de 1997 na verso 1.20.
Eu adicionei a anedota da Perl Conference em 18 de Novembro de 1997 na verso 1.27.
Eu mudei de ``software livre'' para ``cdigo aberto'' em 9 de fevereiro de 1998 na verso 1.29.
Eu adicionei ``Eplogo: Netscape Acata o Bazar!'' em 10 de Fevereiro de 1998 na verso 1.31.
Eu removi o grfico de Paul Eggert sobre GPL vs. bazar em resposta aos argumentos
coerentes de RMS em 28 de Julho de 1998.
Eu adicionei uma correo de Brooks baseado nos Documentos Halloween em 20 de
Novembro de 1998 na verso 1.40.
Outros nveis de revises incorporaram pequenas correes editoriais.