Lei de Linus

A Lei de Linus (Linus' Law) é uma lei epigramática formulada pelo hacker Eric S. Raymond.^[1] O enunciado dele é o seguinte:

“

Dados olhos suficientes, todos os erros são óbvios" (Given enough eyeballs, all bugs are shallow)

”

A frase possui relação com o modo de funcionamento da base do código aberto (open source) e da internet no qual, contando com um grande número de colaboradores ("olhos"), qualquer problema em um sistema pode ser detectado e corrigido. Na proporção em que os colaboradores aumentam, a facilidade com que as correções são feitas também aumenta, ou seja, o número de colaboradores é diretamente proporcional à facilidade de detecção e correção do erro.

Surgimento e uso

O adágio foi publicado por Eric S. Raymond — um famoso hacker e ícone no movimento do código aberto e do software livre — em seu ensaio A Catedral e o Bazar, descrito no capítulo 10 ("O Contexto Social do Código Aberto"). O nome da lei é uma alusão ao finlandês Linus Torvalds, criador do sistema operacional Linux, um software livre.

Os conceitos expressados pela Lei de Linus são tão universais que a lei tem sido constantemente usada fora do contexto puramente informático. Um exemplo é a Wikipédia, que segue um modelo baseado na lei de Linus, já que, podendo ser editada por qualquer pessoa, muitos erros podem ser gerados, mas se houver um grande número de colaboradores para cuidar dos erros, eles podem ser facilmente identificados e corrigidos. Isso é bem conhecido pelos administradores (ou sysops) de cada Wikipédia, que cuidam da manutenção do projeto.

Larry Sanger, cofundador da Wikipédia, afirmou certa vez, sobre o fato de qualquer pessoa poder criar e editar artigos na Wikipédia, que "dados olhos suficientes, todos os erros são óbvios", em uma alusão direta à lei de Linus.

Tom Arriola, o desenvolvedor do Crime Scene (Cena do Crime), um site que dá aos seus milhares de membros a tarefa de resolver coletivamente mistérios de assassinatos fictícios, chamou de "efeito ocular" uma versão que postulou da Lei de Linus: "Quanto mais olhos veem algo, mais provável é que alguém veja alguma coisa que ninguém viu antes."^[2]

A ética hacker

A noção do próprio Linus sobre a lei foi usada em conjunto com as definições filosóficas do hacker ativo, registrada no prólogo do livro A Ética Hacker.^[3]

De acordo com essa definição, a atividade que pressiona os humanos pode ser dividida em três categorias. O avanço bem-sucedido de uma fase para outra determina o processo de evolução. Estas três categorias são, em ordem: a sobrevivência, a vida social e o entretenimento.

A sobrevivência é a base da própria existência. É portanto um fator de motivação, mas em um sistema socioeconômico bem desenvolvido, não passa de uma preocupação cotidiana.

A vida social é um fator de motivação muito forte. Em muitos casos, maior consideração é dada para os laços sociais do que para a "auto-pessoa". São tarefas semelhantes aos conceitos de "morrer por sua família/por religião/pelo país".

O entretenimento é a última das três categorias. Esse "entretenimento" não está relacionado com ações como jogar jogos eletrônicos ou assistir a televisão, mas fazer algo interessante e estimulante, um estímulo positivo para a base de nossas ações. Linus Torvalds assim descreveu esta última fase: "É a ginástica mental necessária na tentativa de explicar o universo".

Pode-se observar a aderência dessas três categorias com as cinco necessidades da conhecida Hierarquia de necessidades de Maslow: fisiologia, segurança, amor/relacionamento, estima e realização pessoal, amplamente conhecidas no terreno da Administração.

Concluindo, o hacker portanto precisará fazer uso do computador para que sobreviva. O computador passa a ser o principal meio de obter relações sociais, mas acima de tudo, entretenimento. O desenvolvimento de um sistema open source é realizada mais por causa da paixão dos desenvolvedores no seu próprio projeto, e não para meios puramente comerciais.

Críticas

Alguns estudos contestaram a Lei de Linus, citando o número relativamente pequeno de contribuições feitas para projetos open source por pessoas "de fora", isto é, pessoas que não pertencem a um pequeno grupo principal de colaboradores.^[4] Isso é, em grande parte, o resultado do investimento necessário que os colaboradores precisam realizar para manter positivamente os ajustes na interface do usuário e entender um pouco do código antes que possam efetivamente contribuir para o mesmo.

Alguns projetos também não confiam em contribuições externas, temendo que eles possam criar defeitos difíceis de serem encontrados ou brechas na segurança, e assim esses projetos criam um inconveniente processo de revisão que pode prejudicar desenvolvimento externo.

Os defensores do código aberto argumentam, no entanto, que existem maneiras de se minimizar estes problemas e de se facilitar a integração de colaboradores externos. Seguindo práticas efetivas de Engenharia de Software, é possível produzir um código de fácil manutenção. Os exemplos podem incluir o uso de componentes modulares com baixo acoplamento, ou um bom conjunto de testes para a verificação das contribuições externas, ou uma simples estratégia de desenvolvimento suportada por ferramentas como o autoconf.

Também é considerada uma ajuda importante o software ter uma boa documentação, incluindo tanto uma visão geral quanto descrições detalhadas da interface, opcionalmente suportadas por ferramentas como o Javadoc e ferramentas de visualização de código. Porém nem todos os projetos open source implementam tais medidas.

Outro argumento contra o código aberto é o de que falhas de segurança podem ser facilmente encontradas pelo exame do código-fonte, destruindo efetivamente qualquer segurança por obscuridade (en:security through obscurity). Outros dizem que isso é um ponto forte: significa que não apenas usuários maliciosos, mas também desenvolvedores externos e usuários legítimos, podem encontrar tal falha de segurança mais facilmente e diagnosticar ataques mais rapidamente. Por serem expostos rapidamente e para mais pessoas, os problemas de segurança podem ser consertados antes que a aplicação esteja completamente desenvolvida e eles se tornem um problema mais sério.