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.