A Catedral e o Bazar

Eric S. Raymond – A Catedral e o Bazar

A Catedral e o Bazar
Eric S. Raymond

1


A Catedral e o Bazar

E r i c S t e v e n R a ym o n d ( T h e C a t h e d r a l & t h e B a z a a r ) – Au t o r
Disponível em:
http://www.catb.org/~esr/writings/cathedral-
bazaar/cathedral-bazaar/
P á g i n a n a We b : h t t p : / / w w w . c a t b . o r g / e s r /

E r i c K o h l e r – Tr a d u t o r
Disponível em:
http://www.geocities.com/CollegePark/Union/3590/
pt-cathedral-bazaar.html
P á g i n a n a We b :
http://www.geocities.com/CollegePark/Union/3590/

Cópia e re distribuiçã o pe rmitida se m roy alty c onta nto que e sta notifica çã o e ste ja pre se rva da .

Tr a d u z i d o p o r E r i k K o h l e r. < e k o h l e r a t p r o g r a m m e r. n e t >

José Lopes O. Júnior – Editor
Disponível em:
http://joselopes.org/documents/a_catedral_eo_baz
ar.pdf
P á g i n a n a We b : h t t p : / / j o s e l o p e s . o r g /

Notas da edição: N o s c a p í t u l os A p re s e n t a ç ã o e L i b e re C e d o , Li b e re F re q u e n t e m e n t e ,
a t r a d u ç ã o o r i g i n a l d a f r a s e d e E r i c R a y m o n d “ Gi v e n e n o u g h e y e b a l l s , a ll b u g s a re
s h a l l o w. ” foi trocada de “ D a d o s b a s t a nt e o l h o s , to d o s o s e r ro s s ã o t r i v i a i s .” para
“ H a v e n d o o l h o s s uf i c i e n t e s , to d o s o s e r ro s s ã o ó b v i o s .” .

03/05/2010

2


Índice

A p r e s e n t a ç ã o .........................................................................................................................4

1 . A C a t e d r a l e o B a z a r .....................................................................................................5

2 . O C o r r e i o D e v e S e r E n t r e g u e ....................................................................................7

3 . A I m p o r t â n c i a d e t e r U s u á r i o s ................................................................................1 2

4 . L i b e r e C e d o , L i b e r e F r e q u e n t e m e n t e ..................................................................1 4

5 . Q u a n d o u m a R o s a n ã o é u m a R o s a ? ...................................................................2 0

6 . p o p c l i e n t t r a n s f o r m a - s e e m f e t c h m a i l .................................................................2 3

7 . f e t c h m a i l C r e s c e ...........................................................................................................2 7

8 . A l g u m a s L i ç õ e s a m a i s d o f e t c h m a i l ....................................................................3 0

9 . P r é - c o n d i ç õ e s N e c e s s á r i a s p a r a o E s t i l o B a z a r .............................................3 3

1 0 . O C o n t e x t o S o c i a l d o C ó d i g o A b e r t o .................................................................3 6

11 . A g r a d e c i m e n t o s ...........................................................................................................4 2

1 2 . P a r a L e i t u r a A d i c i o n a l .............................................................................................4 3

1 3 . E p í l o g o : N e t s c a p e A c a t a o B a z a r ! ......................................................................4 5

1 4 . Ve r s ã o e H i s t ó r i c o d e M u d a n ç a s .........................................................................4 7

3


Apresentação

Eu analiso um projeto bem sucedido de código livre, o fetchmail,
que foi executado como um teste deliberado de algumas teorias surpreendentes
sobre a tecnologia de programação sugerida pela história do Linux. Eu discuto
estas teorias nos termos de dois estilos fundamentais diferentes de
desenvolvimento, o modelo C AT E D R A L da maior parte do mundo comercial contra
o modelo BAZAR do mundo do Linux. Eu mostro que estes modelos derivam de
s u p o s i ç õ e s o p o s t a s s o b r e a n a t u r e z a d a t a r e f a d e d e p u r a r o s o f t w a re . E u f a ç o
então um argumento sustentado na experiência do Linux para a proposição que
“ H a v e n d o o l h o s s u f i c i e n t e s , t o d o s o s e r ro s s ã o ó b v i o s . ” , s u g i r o a n a l o g i a s
produtivas com outros sistemas auto-corrigíveis de agentes egoístas e concluo
com alguma exploração das implicações desta introspecção para o futuro do
s o f t w a re .

4


1. A Catedral e o Bazar

Linux é subversivo. Quem pensaria, mesmo há cinco anos atrás,
que um sistema operacional de classe mundial poderia surgir como que por
mágica pelo tempo livre de milhares de colaboradores espalhados por todo o
planeta, conectados somente pelos tênues cordões da Internet?

Certamente não eu. No tempo em que o Linux apareceu em minha
tela-radar no início de 1993, eu já tinha me envolvido no desenvolvimento de
Unix e de código aberto por dez anos. Eu fui um dos primeiros contribuintes
p a r a o p r o j e t o G N U e m m e a d o s d e 1 9 8 0 . E u t i n h a l i b e r a d o b a s t a n t e d o s o f t w a re
livre na rede, desenvolvendo ou co-desenvolvendo diversos programas ( nethack,
Emacs em modo VC e GUD, xlife e outros) que estão ainda em largo uso hoje.
Eu pensei que eu sabia como isso era feito.

O Linux ultrapassou muito o que eu pensei que sabia. Eu estava
pregando o modo Unix de uso de pequenas ferramentas, de prototipagem rápida
e de programação evolucionária por anos. Mas eu acreditei também que havia
alguma complexidade crítica, acima da qual uma aproximação mais
c e n t r a l i z a d a , m a i s a p r i o r i e r a r e q u e r i d a . E u a c r e d i t a v a q u e o s s o f t w a re s m a i s
importantes (sistemas operacionais e ferramentas realmente grandes como
Emacs) necessitavam ser construídos como as catedrais, habilmente criados com
cuidado por mágicos ou pequenos grupos de magos trabalhando em esplêndido
isolamento, com nenhum beta para ser liberado antes de seu tempo.

O e s t i l o d e L i n u s To r v a l d s d e d e s e n v o l v i m e n t o – l i b e r e c e d o e
frequentemente, delegue tudo que você possa, esteja aberto ao ponto da
promiscuidade – veio como uma surpresa. Nenhuma catedral calma e respeitosa
aqui – ao invés, a comunidade Linux pareceu assemelhar-se a um grande e
barulhento bazar de diferentes agendas e aproximações (adequadamente

5


simbolizada pelos repositórios do Linux, que aceitaria submissões de qualquer
pessoa) de onde um sistema coerente e estável poderia aparentemente emergir
somente por uma sucessão de milagres.

O fato de que este estilo bazar pareceu funcionar e funcionar bem,
v e i o c o m o u m d i s t i n t o c h o q u e . C o n f o r m e e u a p r e n d i a a o m e u r e d o r, t r a b a l h e i
duramente não apenas em projetos individuais, mas também tentando
compreender porque o mundo do Linux não somente não se dividiu em confusão
mas parecia aumentar a sua força a uma velocidade quase inacreditável para os
construtores de catedrais.

Em meados de 1996 eu pensei que eu estava começando a
c o m p r e e n d e r. O a c a s o d e u - m e u m a m a n e i r a p e r f e i t a p a r a t e s t a r m i n h a t e o r i a , n a
forma de um projeto de código aberto que eu poderia conscientemente tentar
e x e c u t a r n o e s t i l o b a z a r. A s s i m e u f i z – e f o i u m s u c e s s o s i g n i f i c a t i v o .

No resto deste artigo eu contarei a história desse projeto e eu irei
usá-la para propor alguns aforismos sobre o desenvolvimento eficaz de código
aberto. Nem tudo eu aprendi primeiramente no mundo do Linux, mas nós
v e r e m o s c o m o o m u n d o d o L i n u x l h e d á u m p o n t o p a r t i c u l a r. S e e u e s t i v e r
correto, eles o ajudarão a compreender exatamente o que é que faz a
c o m u n i d a d e d o L i n u x s e r u m a f o n t e d e s o f t w a re b o m – e a j u d a a v o c ê a s e
tornar mais produtivo.

6


2. O Correio Deve Ser Entregue

Desde 1993 eu venho cuidando da parte técnica de um pequeno
Provedor de Acesso Internet de acesso gratuito chamado Chester County
I n t e r L i n k ( C C I L ) e m We s t C h e s t e r , P e n s i l v â n i a ( e u f u i c o - f u n d a d o r d o C C I L e
e s c r e v i n o s s o s o f t w a re m u l t i u s u á r i o d e B B S – v o c ê p o d e o b s e r v á - l o e x e c u t a n d o
um telnet para locke.ccil.org. Hoje suporta quase três mil usuários em
trinta linhas.). O trabalho permitiu-me o acesso 24 horas por dia à rede através
da linha de 56K do CCIL – de fato, praticamente exigiu!

Consequentemente, eu fiquei acostumado a acesso instantâneo ao
correio Internet. Por razões complicadas, era difícil fazer o SLIP funcionar
entre minha máquina de casa ( snark.thyrsus.com) e o CCIL. Quando eu
finalmente consegui, eu achei incômodo ter que executar telnet periodicamente
para o locke para verificar meu correio. O que eu queria era que ele fosse
enviado para o snark de modo que eu fosse notificado quando uma mensagem
chegasse e pudesse manuseá-lo usando todas as minhas ferramentas locais.

O simples reenvio do sendmail não funcionaria, porque minha
máquina local não está sempre na rede e não tem um IP estático. O que eu
precisava era um programa que pegasse meu correio através da conexão SLIP e
o entregasse localmente. Eu sabia que tais programas existiam e que a maioria
deles usava um protocolo de aplicação simples chamado POP ( Post Office
P ro t o c o l ) . E , r e a l m e n t e , j á h a v i a u m s e r v i d o r P O P 3 i n c l u í d o c o m s i s t e m a
operacional BSD/OS do locke.

Eu precisava de um cliente POP3. Então eu procurei na Internet e
encontrei um. Na verdade, eu encontrei três ou quatro. Eu usei o pop-perl por
algum tempo, mas faltava o que parecia uma característica óbvia, a habilidade
de alterar os endereços no correio recebido para que as respostas fossem

7


enviadas corretamente.

O problema era este: suponha que alguém chamado joe no locke
tenha me enviado uma mensagem. Se eu capturasse o correio para o snark e
t e n t a s s e e n t ã o l h e r e s p o n d e r, m e u p r o g r a m a d e c o r r e i o t e n t a r i a a l e g r e m e n t e
enviá-lo a um joe inexistente no snark. Editar manualmente os endereços de
resposta para adicionar @ccil.org rapidamente tornou-se um tormento.

Isto era claramente algo que o computador teria que fazer para
mim. Mas nenhum dos clientes POP existentes sabiam como! E isto nos traz à
primeira lição:

1 . To d o b o m t r a b a l h o d e s o f t w a r e c o m e ç a c o l o c a n d o o d e d o n a
f e r i d a d e u m p r o g r a m a d o r.
Ta l v e z i s t o d e v e r i a t e r s i d o ó b v i o ( u m a n t i g o p r o v é r b i o d i z q u e
“A necessidade é a mãe da invenção” ) mas muitas vezes os programadores
gastam seus dias buscando retorno em programas que eles não necessitam nem
gostam. Mas não no mundo do Linux – o que pode explicar porque a qualidade
m é d i a d o s o f t w a re o r i g i n a d a n a c o m u n i d a d e d e L i n u x é t ã o a l t a .

Assim, eu me lancei imediatamente com o ímpeto de codificar um
novo cliente POP3 para competir com os existentes? De maneira alguma! Eu
olhei com cuidado os utilitários POP que eu tinha à disposição, perguntando-me
“ q u a l d e l e s é o m a i s p r ó x i m o d o q u e e u q u e ro ? ” . P o r q u e . . .

2 . O s p r o g r a m a d o r e s b o n s s a b e m o q u e e s c r e v e r. O g r a n d e s
sabem o que rescrever (e reusar).
E m b o r a e u n ã o m e c o n s i d e r e u m g r a n d e p r o g r a m a d o r, e u t e n t o m e
passar por um. Uma importante característica dos grandes é a preguiça
construtiva. Eles sabem que você ganha um A, não por esforço, mas por
resultados e é quase sempre mais fácil partir de uma boa solução parcial do que

8


do nada.

L i n u s To r v a l d s , p o r e x e m p l o , n ã o t e n t o u r e a l m e n t e e s c r e v e r L i n u x
do nada. Ao contrário, ele começou reusando código e idéias do Minix, um
pequeno sistema operacional Unix-like para máquinas 386. Eventualmente todo
o código Minix se foi, ou foi completamente rescrito – mas quando estava lá,
forneceu as bases para o infante que se transformaria no Linux.

Com o mesmo pensamento, eu fui procurar um utilitário POP que
fosse razoavelmente bem codificado, para usar como uma base de
desenvolvimento.

A tradição do mundo Unix de compartilhar o código fonte foi
sempre amigável para a reutilização de código (esta é a razão porque o projeto
de GNU escolheu o Unix como sistema operacional base, apesar das sérias
reservas sobre o mesmo). O mundo Linux tem levado esta tradição quase a seu
limite tecnológico; tem terabytes de códigos abertos amplamente disponíveis.
A s s i m g a s t a n d o t e m p o p r o c u r a n d o a l g u m s o f t w a re q u a s e - b o m - o - b a s t a n t e f e i t o
por alguém é mais provável dar a você mais bons resultados no mundo Linux do
q u e e m q u a l q u e r o u t r o l u g a r.

E fez para mim. Com aqueles que eu achei antes, minha segunda
b u s c a c o m p ô s u m t o t a l d e n o v e c a n d i d a t o s – f e t c h p o p , P o p Ta r t , g e t - m a i l ,
gwpop, pimp, pop-perl, popc, popmail e upop. O primeiro que eu trabalhei
primeiramente era o fetchpop por Seung-Hong Oh. Eu pus o meu código de
reescrita de cabeçalho nele e fiz várias outras melhorias que o autor aceitou em
sua versão 1.9.

Algumas semanas mais tarde, entretanto, eu tropecei pelo código
do popclient desenvolvido por Carl Harris e descobri que eu tinha um problema.
Embora o fetchpop tenha tido algumas idéias boas e originais (tal como o modo

9


daemon), podia somente trabalhar com POP3 e foi codificado de uma maneira
um tanto amadora (Seung-Hong era um programador brilhante porém
inexperiente e ambas as características ficaram evidentes). O código de Carl era
m e l h o r, b a s t a n t e p r o f i s s i o n a l e s ó l i d o , m a s e m s e u p r o g r a m a f a l t o u d i v e r s a s
características importantes e complicadas de serem implementadas do fetchpop
(incluindo aquelas que eu implementei).

Ficar ou trocar? Se eu trocasse, eu estaria jogando fora o código
que eu já havia feito em troca de uma base melhor do desenvolvimento.

Um motivo prático para trocar era a presença de suporte para
vários protocolos. POP3 é o protocolo mais comumente utilizado de todos os
protocolos de correio dos servidores, mas não o único. fetchpop e os outros
concorrentes não faziam POP2, RPOP ou APOP e eu estava realmente tendo
alguns pensamentos de talvez adicionar IMAP ( Internet Message Access
P ro t o c o l o u P r o t o c o l o d e A c e s s o a M e n s a g e m d a I n t e r n e t – o m a i s r e c e n t e e
p o d e r o s o p r o t o c o l o d e c o r r e i o d e s e n v o l v i d o ) s ó p a r a m e d i v e r t i r.

Mas eu tinha uma razão mais teórica para pensar que trocar seria
uma boa idéia, alguma coisa que eu aprendi muito antes do Linux.

3. “Planeje jogar algo fora; você irá, de qualquer maneira.”
( F r e d B r o o k s , “ T h e M y t h i c a l M a n - M o n t h ” , C a p í t u l o 11 )
Ou, colocando de outra forma, você frequentemente não entende
realmente o problema até depois da primeira vez que você implementa uma
solução. Na segunda vez, talvez você saiba o suficiente para fazer
corretamente. Então se você quer fazer algo certo, esteja preparado para
começar tudo novamente pelo menos uma vez.

Bem (eu disse para mim mesmo) as mudanças no fetchpop foram a
minha primeira tentativa. Então eu troquei.

10


Depois que eu mandei meu primeiro conjunto de alterações para
Carl Harris em 25 de junho de 1996, eu percebi que na verdade ele perdera o
interesse pelo popclient há algum tempo até então. O código era um pouco
empoeirado, com pequenos erros. Eu tinha muitas mudanças para fazer e nós
rapidamente concordamos que o lógico para eu fazer era tomar conta do
programa.

S e m p e r c e b e r, o p r o j e t o h a v i a s e i n t e n s i f i c a d o . E u n ã o e s t a v a
mais contemplando somente pequenos consertos para um cliente POP existente.
Eu estava mantendo um cliente completo e havia idéias borbulhando na minha
cabeça que eu sabia iriam provavelmente levar a importantes mudanças.

E m u m a c u l t u r a d e s o f t w a re q u e e n c o r a j a a t r o c a d e c ó d i g o , i s t o é
u m c a m i n h o n a t u r a l p a r a u m p r o j e t o e v o l u i r. E u e s t a v a r e p r e s e n t a n d o i s t o :

4. Se você tem a atitude certa, problemas interessantes irão
encontrá-lo.
Mas a atitude do Carl Harris foi ainda mais importante. Ele
entendeu que:

5. Quando você perde interesse em um programa, sua última
obrigação a fazer com ele é entregá-lo a um sucessor competente.
Sem ao menos ter que discutir isso, Carl e eu sabíamos que nós
tínhamos um objetivo em comum de ter a melhor solução disponível. A única
questão para nós foi se eu poderia me estabelecer como um par de mãos seguras
para isso. Uma vez que eu tenha feito isso, ele agiu com cortesia e rapidez. Eu
espero que eu aja assim quando chegar a minha vez.

11


3. A Importância de ter Usuários

E então eu herdei o popclient. Tão importante quanto, eu herdei
os usuários do popclient. Usuários são ótimas coisas para se ter e não 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 força da tradição do Unix, uma que o Linux tem levado a um
alegre extremo, é que muitos usuários são hackers também. E porque o código
fonte está disponível, eles podem ser hackers eficazes. Isto pode ser
tremendamente útil para reduzir o tempo de depuração. Com um pouco de
estímulo, seus usuários irão diagnosticar problemas, sugerir correções e ajudar
a melhorar o código muito mais rapidamente do que você poderia fazer sem
ajuda.

6 . Tr a t a r s e u s u s u á r i o s c o m o c o - d e s e n v o l v e d o r e s é s e u c a m i n h o
mais fácil para uma melhora do código e depuração eficaz.
O p o d e r d e s t e e f e i t o é f á c i l d e s e s u b e s t i m a r. D e f a t o , t o d o s n ó s
do mundo do código aberto subestimamos drasticamente como isto iria
incrementar o número de usuários e diminuir a complexidade do sistema, até
q u e L i n u s To r v a l d s n o s m o s t r o u d e o u t r a f o r m a .

De fato, eu penso que a engenhosidade do Linus e a maior parte
do que desenvolveu não foram a construção do kernel do Linux em si, mas sim a
sua invenção do modelo de desenvolvimento do Linux. Quando eu expressei esta
opinião na sua presença uma vez, ele sorriu e calmamente repetiu algo que
f r e q u e n t e m e n t e d i z : “ S o u b a s i c a m e n t e u m a p e s s o a m u i t o p re g u i ç o s a q u e g o s t a
d e g a n h a r c r é d i t o p o r c o i s a s q u e o u t r a s p e s s o a s re a l m e n t e f a z e m . ” P r e q u i ç o s o
como uma raposa. Ou, como Robert Heinlein teria dito, muito preguiçoso para

12


f a l h a r.

Em retrospecto, um precedente para o sucesso e métodos do Linux
pode ser observado no desenvolvimento da biblioteca do GNU Emacs Lisp e os
repositórios de código Lisp. Em contraste com o estilo de desenvolvimento
c a t e d r a l d o n ú c l e o d o E m a c s C e a m a i o r i a d a s o u t r a s f e r r a m e n t a s d a F S F, a
evolução do grupo de código Lisp foi fluída e bastante dirigida ao usuário.
Idéias e protótipos foram frequentemente reescritos três ou quatro vezes antes
de atingirem uma forma estável final. E colaborações permitidas pela Internet,
a la Linux, foram frequentes.

Realmente, minha mais bem sucedida codificação anterior ao
fetchmail foi provavelmente o modo Emacs VC, uma colaboração do tipo do
Linux por email com três outras pessoas, somente uma das quais (Richard
Stallman, o autor do Emacs e fundador da FSF) eu conheci pessoalmente até
h o j e . F o i u m f ro n t - e n d p a r a S C C S , R C S e p o s t e r i o r m e n t e C V S p e l o E m a c s q u e
oferecia operações de controle de versão “um toque ”. Evoluiu de um pequeno e
grosseiro modo sccs.el que alguém havia escrito. E o desenvolvimento do VC
foi bem sucedido porque, ao contrário do próprio Emacs, o código do Emacs
Lisp poderia ir por gerações de lançamento/teste/aperfeiçoamento muito
rapidamente.

13


4. Libere Cedo, Libere Frequentemente

Liberações novas e frequentes são uma parte crítica do modelo de
desenvolvimento do Linux. A maioria dos desenvolvedores (incluindo eu)
costumava acreditar que esta era uma má política para projetos maiores que os
triviais, porque versões novas são quase por definição cheias de erros e você
não quer acabar com a paciência dos seus usuários.

Esta crença reforçou o compromisso de todos com o estilo de
desenvolvimento catedral. Se o principal objetivo era o de usuários verem
menos erros quanto possível, por que então você iria somente lançar um em
cada seis meses (ou frequentemente menos) e trabalhar como um cachorro
depurando entre as liberações. O núcleo do Emacs C foi desenvolvido desta
forma. A biblioteca Lisp, de fato, não foi – porque havia repositórios Lisp
a t i v o s f o r a d o c o n t r o l e d a F S F, a o n d e v o c ê p o d e r i a i r p a r a a c h a r v e r s õ e s n o v a s
e em desenvolvimento, independentemente do ciclo de liberação do Emacs.

A mais importante destas, o repositório elisp do Estado de Ohio,
antecipou o espírito e muitas das características dos atuais grandes repositório
de Linux. Mas poucos de nós realmente pensaram muito sobre o que estávamos
fazendo, ou sobre o que a existência deste repositório sugeriu sobre problemas
n o m o d e l o d e d e s e n v o l v i m e n t o c a t e d r a l d a F S F. E u f i z u m a s é r i a t e n t a t i v a p o r
volta de 1992 para ter bastante código de Ohio formalmente fundido na
biblioteca oficial do Emacs Lisp. Encontrei problemas políticos 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 saudável estava
acontecendo. A política de desenvolvimento aberta do Linus era exatamente o
o p o s t o d o m o d e l o d e d e s e n v o l v i m e n t o c a t e d r a l . O s r e p o s i t ó r i o s s u n s i t e e t s x - 11

14


estavam germinando, múltiplas distribuições estavam surgindo. E tudo isto foi
guiado por uma frequência desconhecida de liberações de núcleo de sistemas.

Linus estava tratando seus usuários como co-desenvolvedores na
maneira mais eficaz possível:

7. Libere cedo. Libere frequentemente. E ouça seus fregueses.
Isso não era muito a inovação do Linus (algo como isso estava
sendo a tradição do mundo Unix por um longo tempo), mas em elevar isto até
um grau de intensidade que alcançava a complexidade do que ele estava
desenvolvendo. Nestes primórdios tempos (por volta de 1991) não 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
colaboração como nenhum outro, isto funcionou.

M a s c o m o i s t o f u n c i o n o u ? E e r a i s t o a l g o q u e e u p o d e r i a d u p l i c a r,
o u e r a a l g o q u e d e p e n d i a d a g e n i a l i d a d e ú n i c a d e L i n u s To r v a l d s ?

Eu não pensei assim. Reconhecidamente, Linus é um excelente
hacker (quantos de nós poderia planejar um kernel completo de um sistema
operacional de qualidade de produção?). Mas o Linux não representou nenhum
salto conceitual impressionante a frente. Linus não é (ou pelo menos, ainda
não) um gênio inovativo de projeto do estilo que, por exemplo, Richard
Stallman ou James Gosling (do NeWS e Java) são. Ao contrário, para mim Linus
parece ser um gênio da engenharia, com um sexto sentido em evitar erros e
desenvolvimentos que levem a um beco sem saída e uma verdadeira habilidade
para achar o caminho do menor esforço 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.

Então, se liberações rápidas e influenciar a Internet a todo custo

15


não foram acidentes mas partes integrantes da perspicácia do gênio de
engenharia do Linus para o caminho do menor esforço, o que ele estava
enfatizando? O que ele estava maquinando?

Posto desta forma, a questão responde a si mesma. Linus estava
mantendo seus usuários/hackers constantemente estimulados e recompensados –
estimulados pela perspectiva de estarem tendo um pouco de ação satisfatória do
ego, recompensados pela visão do constante (até mesmo diário) melhoramento
do seu trabalho.

Linus estava diretamente direcionado a maximizar o número de
pessoas-hora dedicadas à depuração e ao desenvolvimento, mesmo com o
possível custo da instabilidade no código e extinção da base de usuários se
qualquer erro sério provasse ser intratável. 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 solução será óbvia para alguém.
Ou, menos formalmente, “Havendo olhos suficientes, todos os
e r ro s s ã o ó b v i o s . ” E u c h a m o i s s o d e : “ L e i d e L i n u s ” .

Minha formulação original foi que todo problema “será
transparente para alguém”. Linus objetou que a pessoa que entende e conserta o
problema não é necessariamente ou mesmo frequentemente a pessoa que
primeiro o caracterizou. “Alguém 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, penso eu, é o centro da diferença fundamental entre os
estilos bazar e catedral. Na visão catedral de programação, erros e problemas

16


de desenvolvimento são difíceis, insidiosos, um fenômeno profundo. Leva
meses de exame minucioso por poucas pessoas dedicadas para desenvolver
confiança de que você se livrou de todos eles. Por conseguinte os longos
intervalos de liberação e o inevitável desapontamento quando as liberações por
tanto tempo esperadas não são perfeitas.

N a v i s ã o b a z a r, p o r o u t r o l a d o , v o c ê a s s u m e q u e e r r o s s ã o
geralmente um fenômeno trivial – ou, pelo menos, eles se tornam triviais muito
rapidamente quando expostos para centenas de ávidos co-desenvolvedores
triturando cada nova liberação. Consequentemente você libera frequentemente
para ter mais correções e como um benéfico efeito colateral você tem menos a
perder se um erro ocasional aparece.

E é isto. É o suficiente. Se a “Lei de Linus ” é falsa, então
qualquer sistema tão complexo como o kernel do Linux, sendo programado por
tantas mãos quantas programam o kernel do Linux, deveria a um certo ponto
tido um colapso sob o peso de interações imprevisíveis e erros “profundos ” não
descobertos. Se isto é verdade, por outro lado, é suficiente para explicar a
relativa falta de erros do Linux.

E talvez isso não deveria ser uma surpresa, mesmo assim. Anos
atrás, sociologistas descobriram que a opinião média 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 nível de
complexidade do kernel de um sistema operacional.

Eu sou grato a Jeff Dutky < dutky@wam.umd.edu > por apontar
que a Lei de Linus pode ser refeita como “Depurar é paralelizável ”. Jeff

17


observa que embora depurar requer que depuradores se comuniquem com algum
desenvolvedor c o o r d e n a d o r, não requer coordenação significante entre
depuradores. Assim não cai vítima para a mesma complexidade quadrática e
custos de gerência que faz ser problemático adicionar desenvolvedores.

Na prática, a perda teórica de eficiência devido à duplicação de
trabalho por depuradores quase nunca parece ser um problema no mundo do
Linux. Um efeito da “política libere cedo e frequentemente ” é minimizar esta
duplicação, propagando consertos rapidamente.

Brooks até mesmo fez uma observação improvisada relacionada à
observação de Jeff: “O custo total de manter um programa amplamente utilizado
é tipicamente 40% ou mais o custo de desenvolvê-lo. Surpreendentemente este
custo é muito afetado pelo número de usuários. Mais usuários acham mais
erros." (minha ênfase)

Mais usuários acham mais erros porque adicionar mais usuários
adiciona mais maneiras diferentes de testar o programa. Este efeito é
amplificado quando os usuários são co-desenvolvedores. Cada um aborda a
tarefa de caracterização de erro com um conjunto perceptivo ligeiramente
diferente e ferramenta analítica, um ângulo diferente do problema. O Efeito
Delphi parece funcionar precisamente por causa desta variação. No contexto
específico da depuração, a variação também tende a reduzir o feito da
duplicação.

Então adicionar mais beta-testers pode não reduzir a
complexidade de um erro “profundo ” corrente do ponto de vista do
d e s e n v o l v e d o r, m a s a u m e n t a a p r o b a b i l i d a d e q u e a f e r r a m e n t a d e a l g u é m i r á d e
encontro ao problema de uma maneira tal que o problema será trivial para esta
pessoa.

18


Linus cobre suas apostas. Caso haja erros sérios, as versões do
kernel do Linux são numeradas de forma que usuários em potencial podem fazer
a escolha de executar a última versão designada “estável ” ou correr o risco de
encontrar erros para obter novas características. Esta técnica não é ainda
formalmente imitada pela maioria dos hackers usuários do Linux, mas talvez
devesse; o fato de que ambas as escolhas estejam disponíveis faz delas mais
atraentes.

19


5. Quando uma Rosa não é uma Rosa?

Te n d o e s t u d a d o o c o m p o r t a m e n t o d o L i n u s e f o r m a d o u m a t e o r i a
sobre como ele foi bem sucedido, eu fiz uma decisão 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 implementação do Carl Harris era muito atrativa, mas
exibia um tipo de complexidade desnecessária comum a vários programadores
em C. Ele tratou o código como centro das atenções e as estruturas de dados
como suporte para o código. Como resultado, o código era muito bonito mas o
projeto da estrutura de dados era ad-hoc e um tanto feio (ao menos pelos altos
padrões deste velho hacker de LISP).

Eu tinha outro propósito para reescrever além de aperfeiçoar o
código e o projeto da estrutura de dados, entretanto. Era evolui-lo para algo
que eu entenderia completamente. Não é nada agradável ser responsável por
consertar erros em um programa que você não entende.

Mais ou menos durante o primeiro mês, então, eu estava
simplesmente seguindo as implicações do projeto básico do Carl. A primeira
m u d a n ç a s é r i a q u e f i z f o i a d i c i o n a r s u p o r t e a o I M A P. E u f i z i s s o r e o r g a n i z a n d o
as rotinas de protocolos em um driver genérico e três tabelas de métodos (para
POP2, POP3 e IMAP). Esta e as mudanças anteriores ilustram o princípio geral
que é bom para os programadores manterem em mente, especialmente em
linguagens como C que não implementam naturalmente tipagem dinâmica:

9. Estrutura de dados inteligentes e código burro trabalham
muito melhor que ao contrário.

20


B r o o k s , C a p í t u l o 11 : “ M o s t re - m e s e u [ c ó d i g o ] e e s c o n d a s u a s
[ e s t r u t u r a s d e d a d o s ] e e u p o d e re i c o n t i n u a r m i s t i f i c a d o . M o s t re - m e s u a s
[ e s t r u t u r a s d e d a d o s ] e e u p ro v a v e l m e n t e n ã o n e c e s s i t a re i d o s e u [ c ó d i g o ] ; e l e
será óbvio.”

De fato, ele disse “gráficos ” e “tabelas”. Mas considerando trinta
anos de terminologias/mudanças culturais, é praticamente o mesmo ponto.

Neste ponto (quase setembro de 1996, mais ou menos seis semanas
desde o início) eu comecei a pensar que uma mudança de nome deveria ser
a d e q u a d a – a f i n a l d e c o n t a s , n ã o e r a m a i s s o m e n t e u m c l i e n t e P O P. M a s e u
hesitei, porque ainda não havia ainda nada genuinamente novo ainda no projeto.
Minha versão do popclient ainda teria que desenvolver uma identidade própria.

Isto mudou radicalmente quando o fetchmail aprendeu como
r e e n v i a r m e n s a g e n s r e c e b i d a s p a r a a p o r t a S M T P. E u i r e i a e s t e p o n t o e m u m
momento. Mas primeiro: Eu disse acima que eu decidi usar este projeto para
t e s t a r m i n h a t e o r i a s o b r e o q u e L i n u s To r v a l d s f e z c o r r e t a m e n t e . C o m o ( v o c ê
pode perguntar) eu fiz isto? Desta forma:

1. Eu liberei cedo e frequentemente (quase nunca menos que uma
vez a cada dez dias; durante períodos de desenvolvimento
intenso, uma vez por dia).
2. Eu aumentei minha lista de beta-testers adicionando à ela todos
que me contatavam sobre o fetchmail.
3. Eu mandei extensos anúncios à lista de beta-testers toda vez que
e u l i b e r a v a , e n c o r a j a n d o a s p e s s o a s a p a r t i c i p a r.
4. E eu ouvia meus beta-testers, questionando-os sobre decisões de
desenvolvimento e incitando-os toda vez que eles mandavam
consertos e respostas.

21


O retorno destas medidas simples foi imediato. Desde o início do
projeto, eu obtive relatórios sobre erros de uma qualidade que a maioria dos
desenvolvedores morreria para t e r, muitas vezes com ótimos consertos
incluídos. Eu obtive críticas severas, obtive mensagens de fãs, obtive sugestões
inteligentes de características. O que leva a:

10. Se você tratar seus beta-testers como seu recurso mais
valioso, eles irão 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 possuía 249 membros e são adicionados dois ou três por semana.

De fato, conforme eu reviso, ao final de maio de 1997, a lista está
começando a perder membros depois do pico de aproximadamente 300 pessoas
por uma razão interessante. Muitas pessoas têm me pedido para exclui-las da
lista porque o fetchmail está trabalhando tão bem para elas que elas não
p r e c i s a m m a i s v e r o t r á f e g o d a l i s t a ! Ta l v e z i s t o s e j a p a r t e d o c i c l o d e v i d a
n o r m a l d e u m p r o j e t o m a d u r o d o e s t i l o b a z a r.

22


6. popclient transforma-se em fetchmail

O verdadeiro ponto de mudança no projeto foi quando Harry
Hochheiser me mandou o seu rascunho de código para reenviar mensagens para
a porta SMTP da máquina cliente. Eu percebi quase imediatamente que uma
implementação segura desta característica 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
aproveitável mas feio – não estava elegante e com muitas pequenas opções por
toda parte. As opções para extrair mensagens coletadas para um arquivo de
mensagens ou saída padrão particularmente me aborreciam, mas eu não
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
u m a g e n t e t r a n s p o r t a d o r d e c o r r e s p o n d ê n c i a ( M TA ) q u a n t o u m a g e n t e l o c a l d e
e n t r e g a ( M D A ) . C o m r e e n v i o S M T P, e l e p o d e r i a r e t i r a r o M D A e s e r s o m e n t e
u m M TA , t r a n s f e r i n d o a s c o r r e s p o n d ê n c i a s p a r a o u t r o s p r o g r a m a s p a r a e n t r e g a
local como o sendmail faz.

Por que se envolver com toda a complexidade de configurar um
agente de entrega de correspondência 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.

23


Há várias lições aqui. Primeira, esta idéia de reenvio por SMTP
foi o primeiro grande retorno que eu obtive por tentar conscientemente emular
os métodos do Linus. Um usuário me deu esta idéia brilhante – tudo que eu tive
que fazer foi entender as implicações.

11 . A m e l h o r c o i s a d e p o i s d e t e r b o a s i d é i a s é r e c o n h e c e r b o a s
i d é i a s d o s s e u s u s u á r i o s . À s v e z e s , a ú l t i m a é m e l h o r.
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 invenção e está somente sendo modesto sobre seu gênio inato. Nós
todos podemos ver o quanto isso funcionou para Linus!

Quando eu mostrei este documento na
c o n f e r ê n c i a d e P e r l , e m a g o s t o d e 1 9 9 7 , L a r r y Wa l l e s t a v a n a
primeira fila. Quando eu li a última linha acima ele gritou
fervorosamente, em um estilo religioso nostálgico, “Diga,
d i g a , i r m ã o ! ” . To d a a a u d i ê n c i a r i u , p o r q u e e l e s s a b i a m q u e
isso também funcionou para o criador do Perl.

Após poucas semanas executando o projeto no mesmo espírito, eu
comecei a ganhar um louvor semelhante não apenas dos meus usuários mas de
outras pessoas que deixaram as palavras escaparem. Eu guardei algumas destas
mensagens; irei olhar para elas novamente algum dia se eu começar a
questionar se a minha vida valeu a pena :-).

Mas há duas lições mais fundamentais aqui, não políticas, que são
gerais para todos os tipos de projeto.

12. Frequentemente, as soluções mais impressionantes e
inovadoras, surgem ao se perceber que o seu conceito do problema estava

24


errado.
Eu estava tentando resolver o problema errado ao desenvolver
c o n t i n u a m e n t e o p o p c l i e n t c o m o u m M TA / M D A c o m b i n a d o c o m t o d o s o s t i p o s
de modos de distribuição local. O projeto do fetchmail precisava ser repensado
d o i n í c i o c o m o u m p u r o M TA , u m a p a r t e d o c a m i n h o n o r m a l d o c o r r e i o d a
I n t e r n e t q u e f a l a S M T P.

Quando você atinge uma parede ao desenvolver – quando você
dificilmente se encontra pensando em algo depois do próximo patch – é,
f r e q u e n t e m e n t e , t e m p o p a r a p e r g u n t a r, n ã o s e v o c ê t e m a r e s p o s t a c e r t a , m a s s e
v o c ê e s t á p e r g u n t a n d o a p e r g u n t a c o r r e t a . Ta l v e z o p r o b l e m a p r e c i s e s e r
reformulado.

Bem, eu reformulei meu problema. Claramente, a coisa certa a
fazer era: 1. codificar o suporte para reenvio por SMTP no driver genérico. 2.
tornar isto o modo padrão. 3. eventualmente desfazer todos os outros modos de
envio, especialmente as opções de enviar-para-arquivo e enviar-para-saída-
padrão.

Eu hesitei sobre o passo 3 por algum tempo, temendo aborrecer os
usuários de longa data do popclient dependentes dos mecanismos alternativos
de envio. Em teoria, eles poderiam imediatamente passar a usar arquivos
.forward ou seus equivalentes não-sendmail para obter os mesmos efeitos. Na
prática a transição poderia ser confusa.

Mas quando eu a fiz, os benefícios provaram-se altos. As partes
obscuras do código do driver sumiram. A configuração ficou radicalmente mais
simples – não mais rastejar a volta atrás do MDA do sistema e da caixa de
correio do usuário, não mais preocupações sobre se o sistema operacional
suportava locking de arquivo.

25


Além 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 não pode acontecer com o reenvio por SMTP porque o receptor
SMTP não retornará OK a não ser que a mensagem possa ser enviada ou pelo
menos reprogramada para um envio mais tarde.

E também a performance aumentou (embora você não perceberia
isso somente com uma execução). Outro benefício não insignificante foi que a
página do manual ficou muito mais simples.

Mais tarde, eu tive que recolocar envio por um MDA local
especificado pelo usuário para permitir o tratamento de algumas situações
obscuras envolvendo SLIP dinâmico. Mas eu encontrei uma maneira muito mais
simples de fazer isto.

A moral? Não hesite em jogar fora características obsoletas
quando você puder fazer isso sem perda de efetividade. Antoine de Saint-
Exupéry (que foi um aviador e projetista de aviões quando ele não estava sendo
o autor de livros clássicos infantis) disse:

13. “A perfeição [em projetar] é alcançada não quando não há
m a i s n a d a a a d i c i o n a r, m a s q u a n d o n ã o h á n a d a p a r a j o g a r f o r a . ”
Quando o seu código está ficando tão bom quanto simples, é
quando você sabe que está correto. E no processo, o projeto do fetchmail
adquiriu uma identidade própria, diferente do ancestral popclient.

Era tempo para a mudança de nome. O novo projeto parecia muito
mais como um irmão do sendmail do que o velho popclient parecia; ambos eram
M TA s , m a s a o n d e o s e n d m a i l p a s s a e e n t ã o e n v i a , o n o v o p o p c l i e n t c o l e t a e
então envia. Então, após 2 meses, eu mudei o nome para fetchmail.

26


7. fetchmail Cresce

L á e s t a v a e u c o m u m p r o j e t o e l e g a n t e e i n o v a d o r, u m c ó d i g o q u e
eu sabia que funcionava bem porque eu usava todos os dias e uma crescente
lista de beta-testers. E gradualmente eu percebia que eu não estava mais
ocupado com uma trivial codificação pessoal que porventura poderia se tornar
útil para algumas pessoas. Eu tinha em minhas mãos um programa que todos os
usuários de um sistema Unix com uma conexão de correio SLIP/PPP realmente
precisavam.

C o m a c a r a c t e r í s t i c a d e r e e n v i o p o r S M T P, e l e p a s s o u m u i t o à
frente da competição para potencialmente se tornar um “category killer”, um
destes programas clássicos que preenchem seu nicho tão completamente que as
alternativas não são somente descartadas como também esquecidas.

Eu penso que você não pode realmente almejar ou planejar um
r e s u l t a d o c o m o e s t e . Vo c ê t e m q u e s e r a t r a í d o p a r a i s s o p o r i d é i a s d e p r o j e t o
tão poderosas que posteriormente os resultados parecem inevitáveis, naturais,
mesmo predestinados. A única maneira de tentar idéias como esta é tendo
muitas idéias – ou tendo o julgamento de engenharia para levar as boas idéias
das outras pessoas além do que estas que as tiveram pensariam que elas
p o d e r i a m i r.

A n d r e w Ta n e n b a u m t e v e a i d é i a o r i g i n a l d e c o n s t r u i r u m U n i x
nativo simples para o 386, para uso como uma ferramenta de ensino. Linus
To r v a l d s l e v o u o c o n c e i t o d o M i n i x p a r a a l é m d o q u e A n d r e w p r o v a v e l m e n t e
pensou que poderia ir – e cresceu para algo maravilhoso. Da mesma forma
(embora em uma menor escala), eu peguei algumas idéias de Carl Harris e
Harry Hochheiser e dei um empurrão. Nenhum de nós foi “original” no sentido
romântico que as pessoas pensam é um gênio. Mas a maioria do

27


d e s e n v o l v i m e n t o d e s o f t w a re c i e n t í f i c o e d e e n g e n h a r i a n ã o é f e i t a p o r u m
gênio original, a mitologia hacker ao contrário.

Os resultados foram todos sempre muito precipitados – de fato, o
tipo de sucesso que qualquer hacker está sempre procurando! E eles
significaram que eu teria que definir meus padrões ainda mais altos. Para fazer
o f e t c h m a i l t ã o b o m c o m o e u e n t ã o a c h a v a q u e p o d e r i a s e t o r n a r, e u t e r i a q u e
escrever não somente para minhas próprias necessidades, mas também incluir e
suportar características necessárias para outros fora do meu relacionamento. E
fazer isto mantendo o programa simples e robusto.

A primeira e mais importante esmagadora característica que eu
e s c r e v i d e p o i s d e p e r c e b e r i s t o f o i o s u p o r t e a m u l t i d ro p – a h a b i l i d a d e d e
capturar correio de caixas de correio que acumularam todas as mensagens para
um grupo de usuários e então destinar cada pedaço de correio para seus
destinatários individuais.

E u d e c i d i a d i c i o n a r o s u p o r t e a o m u l t i d ro p e m p a r t e , p o r q u e
alguns usuários estavam pedindo por isto, mas principalmente porque eu pensei
que isto retiraria os erros do código para o envio simples, forçando-me a
m a n i p u l a r o e n d e r e ç a m e n t o d e u m m o d o g e r a l . E a s s i m s e p r o v o u s e r. F a z e r
funcionar a análise da RFC 822 me tomou um tempo consideravelmente longo,
não porque qualquer pedaço dele é difícil mas porque envolvia uma pilha de
detalhes interdependentes e elaborados.

M a s o e n d e r e ç a m e n t o m u l t i d ro p s e t o r n o u u m a d e c i s ã o d e p r o j e t o
excelente. Aqui está como eu soube:

14. Qualquer ferramenta deve ser útil da maneira esperada,
mas uma ferramenta verdadeiramente BOA leva ela própria a usos que você
nunca esperou.

28


O uso inesperado para o m u l t i d ro p d o f e t c h m a i l é e x e c u t a r
mailing lists com a lista mantida e expansão de apelidos feita, no lado do
c l i e n t e d a c o n e x ã o S L I P / P P P. I s t o s i g n i f i c a q u e a l g u é m e x e c u t a n d o u m a
máquina pessoal por uma conta ISP pode administrar uma mailing list sem
a c e s s o c o n t í n u o a o s a r q u i v o s d e a p e l i d o s d o I S P.

Outra importante mudança solicitada pelos meus beta-testers foi
s u p o r t e p a r a o p e r a ç ã o M I M E 8 - b i t . I s t o f o i m u i t o f á c i l d e f a z e r, p o r q u e e u
estava sendo cuidadoso mantendo o código pronto para 8-bit. Não porque eu
antecipei a demanda para esta característica, mas em obediência a outra regra:

15. Quando escrevendo um software gateway de qualquer tipo,
faça tudo para perturbar o conjunto de dados o menos possível – e NUNCA

jogue fora informação, a não ser que o destinatário force você a isto!
Se eu não tivesse obedecido esta regra, o suporte a MIME 8-bit
teria sido difícil e cheio de erros. Como estava, tudo o que tive que fazer foi
ler a RFC 1652 e adicionar um pouco de lógica trivial para a geração de
cabeçalho.

Alguns usuários europeus insistiram para que eu adicionasse uma
opção para limitar o número de mensagens recebidas por seção (de maneira que
eles poderiam controlar custos das suas caras redes de telefone). Eu resisti por
um longo tempo e ainda não estou inteiramente alegre sobre isto. Mas se você
está escrevendo para o mundo, você tem que ouvir os seus clientes – isto não
muda somente porque eles não estão pagando dinheiro a você.

29


8. Algumas Lições a mais do fetchmail

A n t e s d e v o l t a r m o s a o a s s u n t o d e e n g e n h a r i a d e s o f t w a re e m
g e r a l , e x i s t e m a l g u m a s l i ç õ e s a m a i s d a e x p e r i ê n c i a d o f e t c h m a i l p a r a p o n d e r a r.

A sintaxe do arquivo rc inclui palavra-chaves “ruidosas”
o p c i o n a i s q u e s ã o i n t e i r a m e n t e i g n o r a d a s p e l o a n a l i s a d o r. A s i n t a x e p a r e c i d a
com o inglês que elas permitem, é consideravelmente mais inteligível que os
concisos pares tradicionais palavra-chave-valor que você obtém quando as
retira.

Estas começaram como um experimento posterior quando eu
percebi como as declarações do arquivo rc estava começando a lembrar uma
minilinguagem imperativa (é por isto também 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 inglês poderia torná-la mais fácil de ser usada. Agora,
embora eu seja um convencido adepto da escola de projeto “faça isso uma
linguagem” como exemplificado pelo Emacs e HTML e muitos sistemas de
banco de dados, eu normalmente não sou um grande fã das sintaxes “English-
like”.

Programadores tradicionais tendem a serem a favor de sintaxes de
controle que são muito precisas e compactas e não contém redundância alguma.
Isto é um legado cultural de quando os recursos computacionais eram caros,
então os estágios de análise tinham que ser tão baratos e simples quanto
possíveis. O inglês, com redundância de aproximadamente 50%, parecia ser um
modelo muito impróprio.

30


Esta não é minha razão para normalmente evitar sintaxes no estilo
do inglês; eu menciono isto aqui somente para arrasá-la. Com ciclos e núcleos
baratos, concisão não deve ser ela mesma um fim. Hoje em dia é mais
importante para uma linguagem ser conveniente para humanos do que ser barata
p a r a o c o m p u t a d o r.

Há, entretanto, boas razões para ser cauteloso. Uma é o custo da
complexidade do estágio de análise – você não quer aumentá-lo ao ponto onde é
uma fonte significativa de erros e confusão de usuários. Outra é que tentar
fazer a sintaxe de uma linguagem English-like frequentemente demanda que o
“inglês” que é falado seja seriamente propenso a ser fora de forma, tanto como
a semelhança superficial com a linguagem natural é tão confusa como a sintaxe
tradicional seria (você vê isso em várias linguagens chamadas de “quarta
geração” e em linguagens de consulta de banco de dados comerciais).

A sintaxe de controle do fetchmail parece evitar estes problemas
porque o domínio da linguagem é extremamente restrito. Não é perto de uma
linguagem de uso geral; as coisas que ela diz simplesmente não são muito
complicadas, então há pouco potencial para confusão em mover mentalmente
entre um pequeno conjunto do inglês e a real linguagem de controle. Eu acho
que há uma lição mais abrangente aqui:

16. Quando sua linguagem não está perto de um Tu r i n g
completo, açúcar sintático pode ser seu amigo.
Outra lição é sobre segurança por obscuridade. Alguns usuários do
f e t c h m a i l m e p e d i r a m p a r a m u d a r o s o f t w a re p a r a g u a r d a r a s s e n h a s e n c r i p t a d a s
no arquivo rc, de maneira que bisbilhoteiros não poderiam casualmente vê-las.

Eu não fiz isso, porque isto não adiciona realmente proteção.
Qualquer pessoa que adquira permissões para ler seu arquivo rc poderá executar
o fetchmail como você de qualquer maneira – e se é a sua senha o que eles

31


procuram, poderiam retirar o decodificador do próprio fetchmail para consegui-
la.

Tu d o o q u e a e n c r i p t a ç ã o d e s e n h a d o a r q u i v o . f e t c h m a i l rc f a r i a
seria dar a falsa impressão de segurança para pessoas que não pensaram bem
sobre este assunto. Aqui a regra geral é:

17. Um sistema de segurança é tão seguro quanto é secreto.
Esteja atento a pseudo-segredos.

32


9. Pré-condições Necessárias para o Estilo Bazar

Os primeiros leitores e audiências para este documento
seguidamente levantaram questões sobre as pré-condições para o
d e s e n v o l v i m e n t o b e m - s u c e d i d o d o e s t i l o b a z a r, i n c l u i n d o a s q u a l i f i c a ç õ e s d o
líder do projeto e o estado do código ao tempo em que se torna público e
começa a tentar construir uma comunidade de co-desenvolvedores.

Está claro que ninguém pode codificar desde o início no estilo
b a z a r. A l g u é m p o d e t e s t a r, a c h a r e r r o s e a p e r f e i ç o a r n o e s t i l o b a z a r, m a s s e r i a
m u i t o d i f í c i l o r i g i n a r u m p r o j e t o n o e s t i l o b a z a r. L i n u s n ã o t e n t o u i s t o . E u
também não. A sua comunidade nascente de desenvolvedores precisa ter algo
e x e c u t á v e l e p a s s í v e l d e t e s t e s p a r a u t i l i z a r.

Quando você começa a construção de uma comunidade, o que você
precisa ter capacidade de apresentar é uma promessa plausível. Seu programa
não precisa funcionar particularmente bem. Ele pode ser grosseiro, cheio de
erros, incompleto, e pobremente documentado. O que não pode deixar de fazer é
convencer co-desenvolvedores em potencial de que ele pode evoluir para algo
realmente elegante em um futuro próximo.

Ta n t o o L i n u x q u a n t o o f e t c h m a i l s e t o r n a r a m p ú b l i c o s c o m
projetos básicos fortes e atraentes. Muitas pessoas pensando sobre o modelo
bazar como eu tenho apresentado têm corretamente considerado isto como
crítico, então concluíram a partir disso que um alto grau de intuição e
inteligência no líder do projeto é indispensável.

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). Então

33


é necessário realmente para o líder/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 não é crítico que o coordenador seja capaz de
originar projetos de excepcional brilho, mas é absolutamente crítico que o
coordenador seja capaz de reconhecer boas idéias de projetos de outras pessoas.

Ta n t o o s projetos do Linux quanto o do fetchmail mostram
evidências disso. Linus, não 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 idéia 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
s o f t w a re é q u e i s t o s e t o r n a u m h á b i t o – v o c ê c o m e ç a r e f l e x i v a m e n t e a f a z e r
coisas atraentes e complicadas quando você deveria mantê-las robutas e
simples. Eu tive projetos que falharam porque eu cometi este erro, mas eu
administrei para que não acontecesse o mesmo com o fetchmail.

Então eu acredito que o projeto do fetchmail foi um sucesso em
parte porque eu impedi a minha tendência a ser engenhoso; isto vai contra (pelo
menos) com o fato de a originalidade em projetar ser essencial para projetos
b e m - s u c e d i d o s n o e s t i l o b a z a r. E c o n s i d e r e o Linux. Suponha que Linus
To r v a l d s e s t i v e s s e t e n t a n d o l e v a r a c a b o i n o v a ç õ e s f u n d a m e n t a i s n o p r o j e t o d e

34


sistemas operacionais durante o desenvolvimento; pareceria que o kernel
resultante seria tão estável e bem-sucedido como é?

Um certo nível básico de habilidade de projetar e codificar é
requerido, claro, mas eu suponho que praticamente qualquer um que pense
seriamente em lançar um esforço no estilo bazar estará acima do mínimo
necessário. O mercado interno da comunidade de s o f t w a re aberto, por
reputação, exerce uma sutil pressão nas pessoas para que não lancem esforço de
d e s e n v o l v i m e n t o q u e n ã o s e j a m c o m p e t e n t e s p a r a m a n t e r. A t é a g o r a i s t o p a r e c e
ter funcionado muito bem.

Há outro tipo de habilidade que não é normalmente associada com
o d e s e n v o l v i m e n t o d e s o f t w a re q u e e u p e n s o é t ã o i m p o r t a n t e q u a n t o a
engenhosidade em planejar projetos no estilo bazar – e isto pode ser mais
importante. Um coorrdenador ou líder de um projeto no estilo bazar deve ter
boa habilidade de comunicação 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
estão fazendo. O entusiasmo técnico constitui uma boa parte para atingir isto,
mas está longe de ser toda história. A personalidade que você projeta também
importa.

Não é uma coincidência que Linus é um rapaz gentil que faz com
que as pessoas gostem dele e que o ajudem. Não é uma coincidência que eu seja
um enérgico extrovertido que gosta de trabalhar com pessoas e tenha um pouco
d e p o r t e e i n s t i n t o d e u m c ô m i c o . P a r a f a z e r o m o d e l o b a z a r f u n c i o n a r, i s t o
ajuda enormemente se você tem pelo menos um pouco de habilidade para
encantar as pessoas.

35


10. O Contexto Social do Código Aberto

Está escrito: os melhores hacks começam como soluções pessoais
para os problemas diários do autor e se espalham porque o problema se torna
típico para uma grande classe de usuários. 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 também comigo e o fetchmail. Mas isso foi entendido por um longo tempo. O
ponto interessante, o ponto que as histórias do Linux e do fetchmail parecem
d e m a n d a r o n o s s o f o c o é o p r ó x i m o e s t á g i o – a e v o l u ç ã o d o s o f t w a re n a
presença de uma comunidade grande e ativa de co-desenvolvedores.

Em “The Mythical Man-Month” , Fred Brooks observou que o
tempo de um programador não é acumulativo; adicionar desenvolvedores em um
p r o j e t o a t r a s a d o d e s o f t w a re f a z c o m q u e e l e s e t o r n e m a i s a t r a s a d o . E l e e x p ô s
que a complexidade e custos de comunicação de um projeto crescem com o
quadrado do número de desenvolvedores, enquanto o trabalho feito cresce
somente linearmente. Esta afirmação é desde então conhecida como a “Lei de
Brooks” e é largamente considerada como correta. Mas se a Lei de Brooks fosse
tudo a ser levado em consideração, o Linux seria impossível.

O clássico “The Psychology of Computer P ro g r a m m i n g ” , de
G e r a l d We i n b e r g , s u s t e n t o u o q u e , e m r e t r o s p e c t i v a , n ó s p o d e m o s v e r c o m o u m a
correção essencial ao Brooks. Em sua discussão sobre “programação sem ego ”,
We i n b e r g o b s e r v o u q u e n o s l u g a r e s o n d e d e s e n v o l v e d o r e s n ã o s ã o t e r r i t o r i a i s
sobre seu código e encorajam outras pessoas a procurar por erros e melhorias
potenciais nele, as melhorias acontecem dramaticamente mais rápidas que em

36


q u a l q u e r o u t r o l u g a r.

A e s c o l h a d a t e r m i n o l o g i a d e We i n b e r g t a l v e z t e n h a p r e v e n i d o s u a
análise de ganhar a aceitação que merecia – é engraçado pensar em descrever os
hackers da Internet como “sem ego ”. Mas acho que seu argumento parece mais
mais convincente hoje do que nunca.

A história do Unix deveria ter sido preparada para nós do que nós
estamos aprendendo com o Linux (e o que eu tenho verificado
experimentalmente em uma menor escala por copiar deliberadamente os
métodos do Linus). Isto é, embora codificar permaneça uma atividade
essencialmente solitária, os hacks realmente bons advém de captar a atenção e
poder de mente de comunidades inteiras. O desenvolvedor que utiliza apenas a
capacidade cerebral dele mesmo em um projeto fechado irá ficar atrás de
desenvolvedores que saibam como criar um contexto aberto e evolutivo no qual
a visualização de erros e melhorias sejam feitas por centenas de pessoas.

Mas o mundo tradicional do Unix foi impedido de seguir
completamente este método por vários fatores. Alguns deles foram os aspectos
legais de várias licenças, segredos de comércio e interesses comerciais. Outro
(tardio) foi que a Internet ainda não estava boa o suficiente.

Antes de a Internet b a r a t e a r, havia algumas comunidades
geograficamente pequenas aonde a cultura motivava a programação “sem ego”
d e We i n b e r g e a o n d e u m d e s e n v o l v e d o r p o d e r i a f a c i l m e n t e a t r a i r m u i t o s c o -
desenvolvedores habilidosos. Bell Labs, o MIT AI Lab, UC Berkeley – estes se
tornaram a origem de inovações que são lendárias e ainda fortes.

Linux foi o primeiro projeto a fazer um esforço consciente e bem-
sucedido a utilizar o mundo inteiro como sua reserva de talentos. Eu não acho
que seja uma coincidência que o período de gestação do Linux tenha coincidido

37


c o m o n a s c i m e n t o d a Wo r l d Wi d e We b e q u e o L i n u x t e n h a d e i x a d o a s u a
infância durante o mesmo período em 1993-1994 que viu a expansão da
indústria de ISP e a explosão do principal interesse da Internet. Linus foi a
primeira pessoa que aprendeu como jogar com as novas regras que a onipresente
Internet fez possível.

Embora uma Internet barata fosse uma condição necessária para
que o modelo do Linux evoluísse, eu penso que não foi uma condição por si só
suficiente. Outro fator vital foi o desenvolvimento de um estilo de liderança e
conjunto de formalidades cooperativas que permitiria aos desenvolvedores
atrair co-desenvolvedores e obter o máximo suporte do ambiente.

Mas o que é este estilo de liderança e estas formalidades? Eles
não podem estar baseados em relações de poder – e mesmo que pudessem, a
l i d e r a n ç a p o r c o e r ç ã o n ã o p r o d u z i r i a o s r e s u l t a d o s q u e n ó s v e m o s . We i n b e r g
cita a autobiografia do anarquista do século 19 chamado Pyotr Alexeyvich
Kropotkin, “Memórias de um Revolucionista” para demonstrar o efeito neste
assunto:

“ Te n d o s i d o c r i a d o e m u m a f a m í l i a p o s s u i d o r a d e v a s s a l o s ,
e u e n t re i à v i d a a t i v a , c o m o t o d o s o s j o v e n s h o m e n s d a m i n h a
idade, com uma grande confidência na necessidade de
c o m a n d a r, o rd e n a r, re p re e n d e r, p u n i r e e t c . M a s q u a n d o c e d o
t i v e q u e c o n d u z i r e m p re e n d i m e n t o s s é r i o s e l i d a r c o m h o m e n s
[ l i v re s ] e q u a n d o c a d a e r ro l e v a r i a d e u m a v e z a s é r i a s
c o n s e q u ê n c i a s , e u c o m e c e i a a p re c i a r a d i f e re n ç a e n t re a t u a r
segundo o princípio de comando e disciplina e atuar segundo
o p r i n c í p i o d a c o m p re e n s ã o c o m u m . O p r i m e i ro f u n c i o n a d e
f o r m a a d m i r á v e l e m u m a p a r a d a m i l i t a r, m a s d e n a d a v a l e
a o n d e a v i d a re a l é c o n s i d e r a d a e o o b j e t i v o p o d e s e r
a t i n g i d o s o m e n t e p e l o e s f o r ç o s e v e ro d e m u i t o s p ro p ó s i t o s

38


c o n v e rg e n t e s . ”

O “esforço s e v e ro de muitos p ro p ó s i t o s c o n v e rg e n t e s ” é
precisamente o que um projeto como o Linux requer – e o “princípio de
comando” é efetivamente impossível de ser aplicado entre voluntários no
paraíso anarquista que nós chamamos de Internet. Para operar e competir
efetivamente, hackers que querem liderar projetos colaborativos têm que
aprender como recrutar e energizar comunidades eficazes com interesse no
modo vagamente sugerido pelo “ p r i n c í p i o d e c o m p re e n s ã o ” sugerido por
Kropotkin. Eles precisam aprender a Lei de Linus.

Inicialmente eu me referi ao Efeito Delphi como uma possível
explicação para a Lei de Linus. Porém, analogias mais poderosas aos sistemas
adaptativos em biologia e economia também se implicam fortemente. O mundo
do Linux se comporta em vários aspectos como um mercado livre ou uma
ecologia, uma coleção de agentes autônomos tentando maximizar um
empreendimento que no processo produz uma ordem espontânea auto-evolutiva
mais elaborada e eficiente que qualquer quantidade de planejamento central
poderia ter alcançado. Aqui, então, é o lugar para procurar o “princípio da
c o m p re e n s ã o ” .

A “função e m p re e n d e d o r a ” que os hackers do Linux estão
maximizando não é economia clássica, mas é a intangível satisfação do seu
próprio ego e reputação entre outros hackers – Alguém pode chamar a sua
motivação de “altruísta”, mas isso ignora o fato que altruísmo é em si mesmo
uma forma de satisfação do ego para um altruísta. Culturas voluntárias que
trabalham desta maneira não são realmente incomuns; uma outra que eu tenho
participado há tempos é os fãs de ficção científica, que ao contrário dos
hackers, explicitamente reconhecem o “egoboo ” (o aumento da reputação de
alguém entre os outros fãs) como o guia básico por trás da atividade voluntária.

39


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-sustentável, tem mostrado um intenso
entendimento do “princípio da compreensão comum ” de Kropotkin. Esta visão
quase-econômica do mundo do Linux nos permite ver como esta compreensão é
aplicada.

Nós podemos ver o método do Linus como uma maneira de criar
um mercado eficiente no “egoboo ” – para ligar a autonomia de hackers
individuais tão firme quanto possível para dificultar fins que podem ser
somente atingidos por uma cooperação sustentada. Com o projeto do fetchmail
eu tenho mostrado (embora em uma menor escala) que seus métodos podem ser
d u p l i c a d o s c o m b o n s r e s u l t a d o s . Ta l v e z e u t e n h a a t é m e s m o f e i t o d e u m a
maneira um pouco mais consciente e sistemática do que ele.

Muitas pessoas (especialmente aquelas que politicamente
desacreditam os mercados livres) poderiam esperar de uma cultura de egoístas
auto-direcionadores ser fragmentada, territorial, desperdiçadora, reservada e
hostil. Mas esta expectativa é claramente desfeita pela (para dar só um
exemplo) imensa variedade, qualidade e profundidade da documentação do
Linux. É notoriamente conhecido que os programadores detestam documentar;
como, então, os hackers do Linux geram tanto disto? Evidentemente o mercado
livre do Linux em egoboo trabalha melhor para produzir comportamentos
virtuosos e direcionados a outros propósitos que os centros de documentação
m a s s i v a m e n t e f u n d a d o s d e p r o d u t o r e s d e s o f t w a re c o m e r c i a l .

Ta n t o o p r o j e t o d o f e t c h m a i l c o m o o d o k e r n e l d o L i n u x m o s t r a m
que ao se recompensar propriamente o ego de muitos outros hackers, um
desenvolvedor/coordenador forte pode usar a Internet para capturar os
benefícios de se ter vários co-desenvolvedores sem fazer o projeto colapsar em
uma confusão caótica. Então eu contra-proponho para a Lei de Brooks o

40


seguinte:

19. Contanto que o coodenador do desenvolvimento tenha uma
mídia pelo menos tão boa quanto a Internet, e saiba como liderar sem coerção,
muitas cabeças são inevitavelmente melhores que uma.

Eu acredito que o futuro do s o f t w a re d e c ó d i g o a b e r t o i r á
pertencer gradativamente a pessoas que saibam como jogar o jogo do Linus,
p e s s o a s q u e d e i x a m p a r a t r á s a c a t e d r a l e a b r a ç a m o b a z a r. I s t o n ã o q u e r d i z e r
que uma visão individual e brilhante não irá mais ter importância; ao contrário,
e u a c r e d i t o q u e o e s t a d o d a a r t e d o s o f t w a re d e c ó d i g o a b e r t o i r á p e r t e n c e r a
pessoas que iniciem de uma visão individual e brilhante, então amplificando-a
através da construção efetiva de uma comunidade voluntária de interesse.

E t a l v e z n ã o s o m e n t e o f u t u r o d o s o f t w a re d e c ó d i g o a b e r t o .
Nenhum desenvolvedor de código 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
têm contribuído para o fetchmail!

Ta l v e z n o f i n a l a c u l t u r a d e c ó d i g o a b e r t o i r á t r i u n f a r n ã o p o r q u e
a c o o p e r a ç ã o é m o r a l m e n t e c o r r e t a o u a “ p r o t e ç ã o ” d o s o f t w a re é m o r a l m e n t e
errada (assumindo que você acredita na última, o que não faz tanto o Linus
c o m o e u ) , m a s s i m p l e s m e n t e p o r q u e o m u n d o d o s o f t w a re d e c ó d i g o f e c h a d o
não pode vencer uma corrida evolucionária com as comunidades de código
aberto que podem colocar mais tempo hábil ordens de magnitude acima em um
problema.

41


11. Agradecimentos

Este documento foi enriquecido através de conversas com um
grande número de pessoas que ajudaram a depurá-lo. Agradecimentos
particulares a Jeff Dutky < dutky@wam.umd.edu >, que sugeriu a formulação
“depuração é paralelizável” e ajudou a desenvolver a análise que se procedeu a
isso. E também a Nancy Lebovitz < nancyl@universe.digex.net> pela sua
s u g e s t ã o q u e e u i m i t e i We i n b e r g a o c i t a r K r o p o t k i n . C r í t i c a s i n c i s i v a s t a m b é m
vieram de Joan Eslinger < wombat@kilimanjaro.engr.sgi.com > e Marty
Franz <marty@net-link.net> da lista de Técnicas Gerais. Sou grato aos
membros do PLUG, o Grupo de Usuários de Linux da Filadélfia, por permitir a
primeira audiência de teste para a primeira versão pública deste documento.
F i n a l m e n t e , o s c o m e n t á r i o s d e L i n u s To r v a l d s f o r a m i m p o r t a n t e s e s e u a p o i o
desde o início foi muito estimulante.

42


12. Para Leitura Adicional

Eu citei várias frases do clássico “ The Mythical Man-Month” de
F r e d e r i c k P. B r o o k p o r q u e , e m m u i t o s a s p e c t o s , s u a s c o n s i d e r a ç õ e s a i n d a
precisam ser mais analisadas. Eu recomendo fortemente a 25a. edição de
aniversário de A d d i s o n - We s l e y (ISBN 0-201-83595-9), que adiciona seu
documento “No Silver Bullet” de 1986.

A nova edição é envolvida por uma inestimável retrospectiva de
20 anos atrasada na qual Brooks admite francamente os poucos julgamentos no
texto original que não resistiram ao teste do tempo. Achei que a retrospectiva
deste documento estava substancialmente completa e fiquei surpreso ao
d e s c o b r i r q u e B r o o k s a t r i b u i p r á t i c a s c o m o o e s t i l o b a z a r à M i c ro s o f t ! ( D e f a t o ,
entretanto, esta atribuição se mostrou errada. Em 1998 nós entendemos dos
Documentos Halloween que a comunidade interna de desenvolvimento da
M i c ro s o f t é e s t r a t i f i c a d a , c o m o t i p o c o m u m d e a c e s s o a o c ó d i g o n e c e s s á r i o
para suportar o bazar muitas vezes nem mesmo possível.)

The Psychology of Computer P ro g r a m m i n g , de Gerald M.
We i n b e r g ( N e w Yo r k , Va n N o s t r a n d R e i n h o l d 1 9 7 1 ) i n t r o d u z i u o c o n c e i t o u m
tanto mal nomeado de "programação sem ego ". Embora ele não estivesse nem
perto de ser a primeira pessoa a perceber a futilidade do “princípio do
comando”, ele foi provavelmente o primeiro a reconhecer e argumentar o ponto
p a r t i c u l a r d e l i g a ç ã o c o m o d e s e n v o l v i m e n t o d e s o f t w a re .

R i c h a r d P. G a b r i e l , c o n t e m p l a n d o a c u l t u r a U n i x d a e r a p r é - L i n u x ,
relutantemente argumentou a favor da superioridade do modelo primitivo do
e s t i l o b a z a r e m s e u d o c u m e n t o L i s p : G o o d N e w s , B a d N e w s , a n d H o w t o Wi n
Big, de 1989. Embora obsoleto em alguns aspectos, este ensaio ainda é muito
cotado entre os fãs do Lisp (incluindo eu). Um correspondente me lembrou que

43


a seção intitulada “O Pior é o Melhor” parece-se mais como uma antecipação
do Linux. O documento está disponível na Wo r l d Wi d e We b em
http://www.naggum.no/worse-is-better.html .

P e o p l e w a re : P ro d u c t i v e P ro j e c t s a n d Te a m s ( N e w Yo r k ; D o r s e t
H o u s e , 1 9 8 7 ; I S B N 0 - 9 3 2 6 3 3 - 0 5 - 6 ) , d e D e M a r c o e L i s t e r, é uma jóia pouco
apreciada na qual fiquei deliciado em ver Fred Brooks citá-la em sua
retrospectiva. Embora pouco do que os autores têm a dizer é diretamente
aplicável às comunidades do código aberto do Linux, as idéias do autor sobre as
condições necessárias para um trabalho criativo é incisivo e válido 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 público. Os documentos “sistemas agóricos ” de
Mark Miller e Eric D r e x l e r, descrevendo as propriedades emergentes de
ecologias computacionais de mercado, me ajudaram a me preparar a pensar
claramente sobre fenômenos análogos na cultura do código aberto quando o
Linux esfregou o meu nariz neles cinco anos depois. Estes documentos estão
d i s p o n í v e i s n a We b e m h t t p : / / w w w . a g o r i c s . c o m / a g o r p a p e r s . h t m l .

44


13. Epílogo: Netscape Acata o Bazar!

É um sentimento estranho perceber que você está ajudando a fazer
história…

Em 22 de janeiro de 1998, aproximadamente sete meses depois
que eu publiquei pela primeira vez este documento, Netscape Communications,
Inc. anunciou planos para liberar o código do Netscape Communicator. Eu não
tive nenhuma idéia de que isso poderia acontecer até o dia do anunciamento.

Eric Hahn, Vi c e Presidente Executivo e Oficial Chefe de
Te c n o l o g i a d a N e t s c a p e , e n v i o u u m a m e n s a g e m p a r a m i m p o u c o t e m p o d e p o i s
como se segue:
“ E m n o m e d e t o d o s d a N e t s c a p e , e u q u e ro a g r a d e c e r a v o c ê
p o r t e r n o s a j u d a d o c h e g a r a e s t e p o n t o e m p r i m e i ro l u g a r.
Seus pensamentos e escritos foram inspirações fundamentais
para nossa decisão.”

N a s e m a n a s e g u i n t e e u v o e i a t é o Va l e d o S i l í c i o a p e d i d o d a
Netscape para uma conferência estratégica de um dia (em 4 de fevereiro de
1998) com alguns de seus executivos de alto escalão e técnicos. Nós
desenhamos juntos a estratégia de lançamento da Netscape para o código fonte
e licenciamento, e deixamos mais alguns planos que nós esperamos irá
eventualmente ter impactos mais abrangentes e positivos na comunidade do
código aberto. Enquanto escrevo, ainda é um pouco cedo demais para ser mais
específico; porém detalhes devem se tornar conhecidos em semanas.

A Netscape está para nos fornecer um real teste em larga escala do
modelo bazar no mundo comercial. A cultura do código aberto agora enfrenta
um risco; se os planos da Netscape não funcionarem, o conceito de código

45


aberto pode se tornar tão desacreditado que o mundo comercial não irá tocar
nele de novo por uma década.

P o r o u t r o l a d o , i s t o t a m b é m é u m a o p o r t u n i d a d e e s p e t a c u l a r.
R e a ç õ e s i n i c i a i s a o m o v i m e n t o e m Wa l l S t r e e t e e m o u t r o s l u g a r e s f o r a m
c a u t e l o s a m e n t e p o s i t i v a s . N ó s t a m b é m e s t a m o s t e n d o a c h a n c e p a r a n o s p r o v a r.
Se a Netscape retomar uma substancial fatia do mercado através deste
m o v i m e n t o , e l a p o d e r á i n i c i a r u m a r e v o l u ç ã o t a r d i a n a i n d ú s t r i a d e s o f t w a re .

O próximo ano deverá ser muito instrutivo e interessante.

46


14. Versão e Histórico de Mudanças

$Id: cathedral-bazaar.sgml,v 1.42 1998/11/22 04:01:20 esr Exp $

● E u l i b e r e i a v e r s ã o 1 . 1 6 n o L i n u x K o n g re s s , e m 2 1 d e m a i o d e 1 9 9 7 .
● Eu adicionei a bibliografia em 7 de julho de 1997 na versão 1.20.
● E u a d i c i o n e i a a n e d o t a d a P e r l C o n f e re n c e e m 1 8 d e n o v e m b r o d e 1 9 9 7 n a
versão 1.27.
● E u m u d e i d e “ s o f t w a re l i v r e ” p a r a “ c ó d i g o a b e r t o ” e m 9 d e f e v e r e i r o d e
1998 na versão 1.29.
● Eu adicionei “Epílogo: Netscape Acata o Bazar!” em 10 de fevereiro de
1998 na versão 1.31.
● Eu removi o gráfico de Paul Eggert sobre GPL vs. bazar em resposta aos
argumentos coerentes de RMS em 28 de julho de 1998.
● E u a d i c i o n e i u m a c o r r e ç ã o d e B ro o k s b a s e a d o n o s D o c u m e n t o s H a l l o w e e n
em 20 de novembro de 1998 na versão 1.40.
● Outros níveis de revisões incorporaram pequenas correções editoriais.

47

A Catedral e o Bazar

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie A Catedral e o Bazar

Ähnlich wie A Catedral e o Bazar (20)

A Catedral e o Bazar