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 demandar o nosso foco, é o próximo estágio - a evolução do software na 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 projeto atrasado de software faz com que ele se torne mais atrasado. Ele expô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 Programming", de Gerald Weinberg, sustentou o que, em retrospectiva, nós podemos ver como uma correção essencial ao Brooks. Em sua discussão sobre "programação sem ego", Weinberg observou que nos lugares onde desenvolvedores não são territoriais 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 qualquer outro lugar.

A escolha da terminologia de Weinberg talvez tenha prevenido sua 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 baratear, havia algumas comunidades geograficamente pequenas aonde a cultura motivava a programação "sem ego" de Weinberg, e aonde um desenvolvedor poderia facilmente atrair muitos co-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 com o nascimento da World Wide Web, e que o Linux tenha deixado a sua 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 liderança por coerção não produziria os resultados que nós vemos. Weinberg cita a autobiografia do anarquista do século 19 chamado Pyotr Alexeyvich Kropotkin, "Memórias de um Revolucionista" para demonstrar o efeito neste assunto:

"Tendo sido criado em uma família possuidora de vassalos, eu entrei a vida ativa, como todos os jovens homens da minha idade, com uma grande confidência na necessidade de comandar, ordenar, repreender, punir e etc. Mas quando cedo tive que conduzir empreendimentos sérios e lidar com homens [livres], e quando cada erro levaria de uma vez a sérias conseqüências, eu comecei a apreciar a diferença entre atuar segundo o princípio de comando e disciplina e atuar segundo o princípio da compreensão comum. O primeiro funciona de forma admirável em uma parada militar, mas de nada vale aonde a vida real é considerada, e o objetivo pode ser atingido somente pelo esforço severo de muitos propósitos convergentes."

O "esforço severo de muitos propósitos convergentes" é 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 "princípio de compreensã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 compreensão".

A "função empreendedora" 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.

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 duplicados com bons resultados. Talvez eu tenha até mesmo feito de uma 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 massivamente fundados de produtores de software comercial.

Tanto o projeto do fetchmail como o do kernel do Linux mostram 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 seguinte:

19. Contanto que o coordenador 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 software de código aberto irá pertencer gradativamente a pessoas que saibam como jogar o jogo do Linus, pessoas que deixam para trás a catedral e abraçam o bazar. Isto não quer dizer que uma visão individual e brilhante não irá mais ter importância; ao contrário, eu acredito que o estado da arte do software de código aberto irá pertencer 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 talvez não somente o futuro do software de código aberto. 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!

Talvez no final a cultura de código aberto irá triunfar não porque a cooperação é moralmente correta ou a "proteção" do software é moralmente errada (assumindo que você acredita na última, o que não faz tanto o Linus como eu), mas simplesmente porque o mundo do software de código fechado 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.