A Catedral e o bazar

No fantástico livro aqui sintetizado, Eric S. Raymond mostra por que o mundo do software fechado não pode vencer a corrida evolucionária contra o software aberto Linux é subversivo. Quem pensaria há cinco anos que um sistema operacional de classe mundial poderia surgir como que por mágica, durante o tempo livre de milhares de colaboradores espalhados por todo o planeta, conectados somente pelos tênues cordões da Internet?

É dessa maneira que Eric S. Raymond, um grande nome na comunidade do software livre, começa seu bombástico livro sobre o estilo Linus Torvalds de desenvolvimento. O artigo de ESR (como é conhecido na comunidade), teve uma enorme repercussão, recebendo grandes críticas assim como grande aceitação. Influenciou grandes empresas de softwares, como a Netscape Communications, que permitiu o acesso ao código fonte do famoso browser Netscape devido ao artigo de ESR. Segundo ESR, o Linux ultrapassou em muito o que ele pensava que sabia. ESR acreditava que grandes softwares (como o kernel do Linux), deveriam ser construídos como catedrais, criadas por grandes magos trabalhando em isolamento, sem que nenhum "beta" fosse liberado antes de seu tempo. ESR estava errado, ele mesmo admite isso em seu artigo. O estilo de Linus Torvalds de desenvolvimento, que diz: "libere cedo e freqüentemente, esteja aberto ao ponto da promiscuidade", foi uma surpresa para ESR. Para ESR, a comunidade Linux se assemelhou a um grande e barulhento bazar, de diferentes agendas e aproximações, onde um sistema estável poderia apenas emergir de um milagre. O milagre de Linus.

Pode parecer sem sentido liberar o seu código freqüentemente, chegando a liberá-lo mais de uma vez por dia (bem no início do kernel, Linus chegou a fazer isso). Quem vai perder tempo olhando os detalhes de cada código liberado?

O mundo.

No mundo do software livre, o mundo é seu programador. Por essas e diversas outras razões é que o estilo de Linus funcionou tão bem. Mas ESR ainda não acreditava nessas idéias. Ele, como antigo programador da comunidade do software livre, estava acostumado com estilos catedrais. ESR resolveu fazer seu próprio teste, com o software atualmente conhecido por "fetchmail".

ESR trabalhava num pequeno provedor de acesso gratuito na Pensilvânia, e estava achando incômodo ter que acessar a máquina do provedor, via sua conexão PPP de casa, para ler e-mails. Decidiu então procurar por um cliente que transferisse seus e-mails da máquina servidor para sua máquina pessoal. Durante essa procura, ESR encontrou vários clientes, mas nenhum deles atendeu suas necessidades. Como estava interessado em experimentar o estilo bazar de Linus, resolveu fazer um que pudesse atender suas necessidades.

Como ESR citou em uma de suas regras: "Todo bom trabalho de software começa colocando-se o dedo na ferida de um programador". Talvez isso devesse ser óbvio (um antigo provérbio diz que "a necessidade é a mão da invenção"). Mas ESR começou a escrever um cliente do zero? Não, seguindo sua segunda regra que diz: "Programadores bons sabem o que escrever. Os grandes sabem o que reescrever (e reusar)". ESR procurou o cliente que chegaria mais próximo de suas necessidades, e o encontrou.

A tradição do mundo Unix de compartilhar o código fonte foi muito útil para ESR. Essa é uma das razões de o movimento pelo software livre continuar até hoje e estar aumentando cada vez mais. Logo, ESR já tinha um cliente em mãos. E borbulharam idéias na mente de ESR quanto ao seu novo projeto, ele já não estava mais apenas mudando um cliente, ele estava mantendo o seu próprio cliente. Diz ESR que em uma cultura de software que encoraja a troca de código, esse é um caminho natural para um projeto evoluir. Se você tem a atitude certa, problemas interessantes irão encontrá-lo. E o mais interessante que o projeto de ESR demonstrou foi a amizade que existe em uma comunidade de software livre, que prega que: "Quando você perde interesse em um programa, sua última obrigação com ele é entregá-lo a um sucessor competente". ESR agora era o verdadeiro coordenador do cliente que ele tanto mudou.

O que ESR percebeu foi que, além de herdar o programa, ele herdou os usuários, uma facção importante da comunidade.Segundo ESR, cultivados de uma maneira correta eles podem se tornar co-desenvolvedores de seu projeto. E foi isso que ele fez, tornando a depuração e a melhoria do código um caminho mais fácil para ele. ESR subestimou essa característica no início, até que Linus provou o contrário com seu Linux. Ele acredita que, de fato, a engenhosidade de Linus não foi a construção do kernel do Linux, e sim o seu modelo de desenvolvimento. Quando ele exteriorizou isto para Linus, o próprio respondeu com calma e tranqüilidade: "Sou apenas uma pessoa muito preguiços a que gosta de receber créditos por coisas que outras pessoas realmente fazem". ESR acredita nisso agora.

Então ESR continuou a desenvolver seu mais novo projeto na visão que Linus ensinou, a visão bazar, liberando cedo e freqüentemente, ouvindo seus usuários, tratando-os como co-desenvolvedores. Não poderia ter funcionado mais corretamente como funcionou.

Na visão catedral de programação, erros e problemas de desenvolvimento são difíceis, insidiosos, algo profundo. Cria-se um desapontamento quando as tão demoradas e esperadas liberações do software não são perfeitas, pois não foram depuradas totalmente.

Por outro lado, na visão bazar, você assume que os erros são triviais. 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. Se esta lei é falsa, então qualquer sistema complexo, como o kernel do Linux, sendo programado por tantas mãos quantas programam o kernel do Linux, tende a ter um colapso em certo ponto e imprevisíveis erros profundos não descobertos. Mas se a lei é verdadeira, por outro lado, já é o suficiente para explicar a relativa falta de erros do Linux.

Utilizando o estilo de Linus, ESR teve seu primeiro grande retorno: um usuário lhe deu a idéia que mudaria e imortalizaria seu software. E estas modificações levaram o software a usos que ESR nunca imaginou. Com seu projeto maduro, ESR considerou que algumas precondições são necessárias para o estilo bazar.

Segundo ESR, ninguém pode codificar desde o início no estilo bazar. A comunidade precisa de algo executável e já com características próprias para testar e utilizar. Quando você começa a construção de uma comunidade, você precisa apresentar uma promessa plausível. Não é preciso que seu programa funcione corretamente, o que você não pode deixar de fazer é convencer seus co-desenvolvedores de que o seu programa tem potencial para fazer aquilo que ele pretende fazer. Mais ainda, ESR concluiu que o desenvolvedor que utiliza apenas sua capacidade mental para um projeto fechado irá ficar atrás dos desenvolvedores que saibam criar um contexto aberto e evolutivo, no qual a visualização de erros e melhorias sejam feitas por centenas de pessoas. O Linux foi o primeiro exemplo disso, e ESR estava certo.

Acredita ESR que o futuro do software livre irá pertencer a pessoas que saibam se comunicar e criar comunidades para seus projetos. E talvez não só o futuro do software livre.

Nenhum desenvolvedor de código fechado pode competir com um conjunto de talentos reunidos. Talvez no final a cultura de software livre triunfe, não porque a cooperação seja moralmente correta ou a proteção do software seja moralmente errada, mas simplesmente porque o mundo do software fechado não pode vencer uma corrida evolucionária contra comunidades de software aberto, cuja forma de desenvolvimento aloca tantos recursos e tempo hábil, que conduz os problemas a um patamar em que é muito mais fácil resolvê-los.