A Catedral e o Bazar - Eric S. Raymond

Sem dúvida que é um marco para o mundo open source. Publicada por Eric S. Raymond e traduzida para o português por Erik Kohler, A Catedral e o Bazar conta toda a história e os primeiros passos do movimento Open Source.

[ Hits: 74.456 ]

Por: Raphael Silva Bastos em 09/11/2006 | Blog: https://area31.net.br


Libere cedo, libere freqüentemente



Liberações novas e freqüentes 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 freqüentemente 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 ativos fora do controle da FSF, aonde você poderia ir para achar versões novas 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 pouco de nós realmente pensou muito sobre o que estávamos fazendo, ou sobre o que a existência deste repositório sugeriu sobre problemas no modelo de desenvolvimento catedral da FSF. Eu fiz uma séria tentativa por 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 oposto do modelo de desenvolvimento catedral. Os repositórios sunsite e tsx-11 estavam germinando, múltiplas distribuições estavam surgindo. E tudo isto foi guiado por uma freqüê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 freqüentemente. 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.

Mas como isto funcionou? E era isto algo que eu poderia duplicar, ou era algo que dependia da genialidade única de Linus Torvalds?

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 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 estar 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 a 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, "Dados olhos suficientes, todos os erros são triviais." Eu chamo isso de: "Lei de Linus".

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 freqüentemente 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, eu penso, é o centro da diferença fundamental entre os estilos bazar e catedral. Na visão catedral de programação, erros e problemas 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.

Na visão bazar, por outro lado, você assume que erros 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. Conseqüentemente você libera freqüentemente 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 <[email protected]> por apontar que a lei de Linus pode ser refeita como "Depurar é paralelizável". Jeff observa que embora depurar requer que depuradores se comuniquem com algum desenvolvedor coordenador, 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 a duplicação de trabalho por depuradores quase nunca parece ser um problema no mundo do Linux. Um efeito da "política libere cedo e freqüentemente" é 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 porcento 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 desenvolvedor, mas aumenta a probabilidade que a ferramenta de alguém irá de encontro ao problema de uma maneira tal que o problema será trivial para esta pessoa.

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.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. A catedral e o bazar
   3. O correio deve ser entregue
   4. A importância de ter usuários
   5. Libere cedo, libere freqüentemente
   6. Quando uma rosa não é uma rosa?
   7. Popclient transforma-se em Fetchmail
   8. Fetchmail cresce
   9. Algumas lições a mais do Fetchmail
   10. Pré-condições necessárias para o estilo bazar
   11. O contexto social do código aberto
   12. Reconhecimentos
   13. Para leitura adicional
   14. Epílogo: Netscape acata o bazar!
   15. Versão e histórico de mudanças
Outros artigos deste autor

Palm na internet via Linux

Leitura recomendada

Instalação básica do Slackware 10 com KDE 3

LookXP-IceWM - Linux leve e com cara de XP

KahelOS - apresentação e dicas

Instalar o Ubuntu Server

Ubuntu - Manual do Iniciante

  
Comentários
[1] Comentário enviado por coffnix em 09/11/2006 - 01:36h

histórico esse artigo.... tanto q fez o dono da netscape mudar de idéia referente à liberação dos códigos fonte do netscape... hehehe

pra vcs verem como isso foi promissor, vejam ae a fundação mozilla com o firefox e o thunderbird.


;)

[2] Comentário enviado por yetlinux em 09/11/2006 - 06:12h

Ouvi dizer que agora ele quer convencer a Sun a liberar os códigos do Java.

[3] Comentário enviado por eneiasramos em 09/11/2006 - 08:24h

Versão em PDF:

http://www.dominiopublico.gov.br/download/texto/tl000001.pdf

:)

[4] Comentário enviado por leoberbert em 09/11/2006 - 08:40h

Fala rapaizzzz Blz de artigo hein?

Continue assim.. abração!!!

[5] Comentário enviado por gnu em 09/11/2006 - 11:58h

Não quero ser chato.. e por favor não me leve a mal... Mas não seria mais pratico ter colocado isso na seção de Links? Você mesmo indicou http://www.geocities.com/CollegePark/Union/3590/pt-cathedral-bazaar.html.
E está tudo la.... valew...

[6] Comentário enviado por eneiasramos em 09/11/2006 - 17:59h

A versão PDF já está publicada na seção Links.

http://www.vivaolinux.com.br/contribuir/links/verLink.php?codigo=2764

Abraço a todos!

[7] Comentário enviado por bestlinux em 10/11/2006 - 09:43h

Falaaa cara..blzzz

Ficou muito roxxx o Artigo :)

Falow!

[8] Comentário enviado por fabio em 10/11/2006 - 12:03h

Fala GNU, neste caso apóio a publicação aqui no VOL. Motivo: a tradução está publicada no Geocities.

Possíveis problemas:

1. Geocities é beeeem mais lento que o VOL;
2. Vai que um dia a conta deixa de existir ou o artigo sai do ar.

Defendo que um texto, principalmente os úteis, estejam sempre espelhados em mais de 1 site, pois tudo nessa vida tem princípio, meio e fim e isso também vale para sites. É mais ou menos o conceito de mirrors de pacotes de distros, se só houvesse um, quando o servidor cair fica todo mundo na mão :)

Um abraço

[9] Comentário enviado por User-kuruma em 10/11/2006 - 14:23h

Excelente, esse texto tem aplicação não só na área de software, mas também traz lições para criação e desenvolvimento de projetos de outras áreas. As lições que se pode extrair do texto tem aplicação nas mais diversas áreas de produção e desenvolvimento de serviços para a sociedade em geral.

[10] Comentário enviado por joseapff em 10/11/2006 - 16:32h

Muito bom esse texto é ima ótima referencia para quem aprecia o codigo livre.

[11] Comentário enviado por yetlinux em 12/11/2006 - 23:36h

E como alguns já escreveram por aí, não aqui, que o site Domínio Público estaria com o pé na cova, nada melhor que relembrar o que ele pode ter de útil.

***

Sun vai abrir mesmo o Java sob GPLv2
http://br-linux.org/linux/sun-confirma-vai-mesmo-abrir-o-codigo-do-java-e-a-licenca-sera-a-gplv2

[12] Comentário enviado por juliaojunior em 18/03/2008 - 20:44h

Simplesmente fantástico!! Vai para o favoritos.


Contribuir com comentário