A Catedral e o Bazar/IV

by Eric S. Raymond

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. Liberece 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 tenndo 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. Consequentemente 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 <dutky@wam.umd.edu> 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.