Bom dia amigos!
Vimos no versículo passado a sexta parte da tradução de “The Cathedral and the Bazaar”. Hoje seguimos com a sétima
Minha formulação original era que todo problema “será transparente para alguém”. Linus contestou que a pessoa que entende e conserta o problema não é necessariamente, ou normalmente, a pessoa que primeiro o caracteriza. “Alguém descobre o problema”, diz ele, “e alguém o entende. E eu vou registrar que encontrá-lo que é o maior desafio”. Essa correção é importante; Vamos ver como na próxima seção, quando examinarmos a prática da depuração em mais detalhes. Mas o ponto chave é que ambas as partes do processo (encontrar e corrigir) tendem a acontecer rapidamente.
Na lei de Linus, penso eu, está a principal diferença subjacente aos estilos de construtor de catedrais e de bazar. Na visão de programação da construção da catedral, bugs e problemas de desenvolvimento são fenômenos profundos, traiçoeiros e complicados. Demora meses de escrutínio por alguns dedicados para desenvolver a confiança de que você apagou todos eles. Assim, os longos intervalos de lançamentos e a inevitável decepção quando os lançamentos aguardados não são perfeitos.
Na visão do bazar, por outro lado, você supõe que os bugs geralmente são fenômenos superficiais – ou, pelo menos, que se tornam superficiais rapidamente quando expostos a milhares de co-desenvolvedores ansiosos em cada nova versão. Consequentemente, você lança frequentemente para obter mais correções e, como efeito colateral benéfico, você tem menos a perder se uma falha ocasional sair pela porta.
E é isso. É o bastante. Se a “Lei de Linus” é falsa, então qualquer sistema tão complexo como o kernel do Linux, sendo ‘hackeado’ por tantas mãos quanto o kernel foi, devia em algum momento ter entrado em colapso sob o peso de imprevistas interações ruins e erros “profundos” não descobertos. Se for verdade, por outro lado, é suficiente explicar a relativa falta de defeitos do Linux e seus contínuo uptime de meses ou até anos.
Talvez não devesse ter sido uma surpresa assim. Há muito tempo os sociólogos descobriram que a opinião média de uma massa de observadores igualmente experientes (ou igualmente ignorantes) é um preditor bastante mais confiável do que a opinião de um único observador escolhido aleatoriamente. Eles chamavam isso de efeito Delphi. Parece que o que Linus mostrou é que isso se aplica mesmo à depuração de um sistema operacional – que o efeito Delphi pode domar a complexidade do desenvolvimento, mesmo no nível de complexidade de um kernel de sistema operacional. [CV]
Uma característica especial da situação do Linux que claramente ajuda ao longo do efeito Delphi é o fato de que os contribuidores de qualquer projeto são auto-selecionados. Um respondente inicial apontou que as contribuições são recebidas não de uma amostra aleatória, mas de pessoas que estão interessadas o suficiente para usar o software, aprender como ele funciona, tentar encontrar soluções para os problemas que encontram e realmente produzir uma correção aparentemente razoável. Qualquer pessoa que passe por todos esses filtros é altamente provável que tenha algo útil para contribuir.
[CV] Que a transparência e a revisão por pares são valiosas para domar a complexidade do desenvolvimento do sistema operacional, afinal, não é um conceito novo. Em 1965, muito cedo na história dos sistemas operacionais de tempo compartilhado, Corbató e Vyssotsky, co-designers do sistema operacional Multics, escreveram:
Espera-se que o sistema Multics seja publicado quando estiver operando substancialmente … Essa publicação é desejável por duas razões: primeiro, o sistema deve resistir ao escrutínio público e às críticas oferecidas pelos leitores interessados; segundo, em uma era de complexidade crescente, é uma obrigação para os projetistas de sistemas presentes e futuros tornar o sistema operacional interno o mais lúcido possível, de modo a revelar os problemas básicos do sistema.
Esta foi a sétima parte da obra, amanhã a oitava. Ricas bençãos!
