Linux: A Catedral e o Bazar

Tecnologia da Informação

(The Cathedral and the Bazaar)

"Mostre-me seu código e esconda suas estruturas de dados,

e eu poderei continuar mistificado.

Mostre-me suas estruturas de dados, e eu provavelmente não

necessitarei do seu código; ele será óbvio."

(Brooks) 

Por Eric S. Raymond

(Traduzido por Erik Kohler - ekohler at programmer.net)*

Trata-se de uma obra sobre métodos de engenharia de software, baseada na experiência do autor com projetos open source. Nele, o autor analisa um projeto bem sucedido de código livre, o Fetchmail, que foi executado como um teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programação sugerida pela história do Linux. 

Ele discute estas teorias nos termos de dois estilos fundamentais diferentes de desenvolvimento, o modelo "catedral'' da maior parte do mundo comercial contra o modelo "bazar'' do mundo do Linux. E mostra que estes modelos derivam de suposições opostas sobre a natureza da tarefa de depurar o software, fazendo então um argumento sustentado na experiência do Linux para a proposição que:

• "Dados bastante olhos, todos os erros são triviais'' 

O autor sugere analogias produtivas com outros sistemas auto-corrigíveis de agentes egoístas, e conclui, a partir da exploração das implicações desta introspeção, algumas conjeturas sobre o futuro do software. Vale a pena conferir este trabalho, em tempos de convergência digital e internet, a partir dos quais  constantes inovações de TI impactam cada vez mais as vidas das pessoas e das organizações.

1. A Catedral e o Bazar Linux é subversivo.

 
Quem pensaria mesmo, há cinco anos atrás, que um sistema operacional de classe mundial poderia surgir como que por mágica pelo tempo livre de milhares de colaboradores espalhados por todo o planeta, conectado somente pelos tênues cordões da Internet? Certamente não eu.

No tempo que o Linux apareceu em minha tela-radar no início de 1993, eu já tinha me envolvido no desenvolvimento de Unix e de código aberto por dez anos. Eu fui um dos primeiros contribuintes para o projeto GNU nos meados de 1980. Eu tinha liberado bastante do software livre na rede, desenvolvendo ou co-desenvolvendo diversos programas (nethack, Emacs em modo VC e GUD, xlife, e outros) que estão ainda em largo uso hoje. 

Eu pensei que eu sabia como isso era feito. Linux ultrapassou muito o que eu pensei que sabia. Eu estava pregando o modo Unix de uso de pequenas ferramentas, de prototipagem rápida e de programação evolucionária por anos. Mas eu acreditei também que havia alguma complexidade crítica, acima da qual uma aproximação mais centralizada, mais a priori era requerida. 

Eu acreditava que os softwares mais importantes (sistemas operacionais e ferramentas realmente grandes como Emacs) necessitavam ser construídos como as catedrais, habilmente criados com cuidado por mágicos ou pequenos grupos de magos trabalhando em esplêndido isolamento, com nenhum beta para ser liberado antes de seu tempo. 

O estilo de Linus Torvalds de desenvolvimento - libere cedo e freqüentemente, delegue tudo que você possa, esteja aberto ao ponto da promiscuidade - veio como uma surpresa. Nenhuma catedral calma e respeitosa aqui - ao invés, a comunidade Linux pareceu assemelhar-se a um grande e barulhento bazar de diferentes agendas e aproximações (adequadamente simbolizada pelos repositórios do Linux, que aceitaria submissões de qualquer pessoa) de onde um sistema coerente e estável poderia aparentemente emergir somente por uma sucessão de milagres. 

O fato de que este estilo bazar pareceu funcionar, e funcionar bem, veio como um distinto choque. Conforme eu aprendia ao meu redor, trabalhei duramente não apenas em projetos individuais, mas também tentando compreender porque o mundo do Linux não somente não se dividiu em confusão mas parecia aumentar a sua força a uma velocidade quase inacreditável para os construtores de catedrais. 

Em meados de 1996 eu pensei que eu estava começando a compreender. O acaso deu-me uma maneira perfeita para testar minha teoria, na forma de um projeto de código aberto que eu poderia conscientemente tentar executar no estilo bazar. Assim eu fiz - e foi um sucesso significativo. 

No resto deste artigo eu contarei a história desse projeto, e eu irei usá-la para propor alguns aforismos sobre
o desenvolvimento eficaz de código aberto. Nem tudo eu aprendi primeiramente no mundo do Linux, mas nós veremos como o mundo do Linux lhe dá um ponto particular. Se eu estiver correto, eles o ajudarão a compreender exatamente o que é que faz a comunidade do Linux ser uma fonte de software bom - e ajuda a você a se tornar mais produtivo.

2. O correio deve ser entregue desde 1993

 
Eu venho cuidando da parte técnica de um pequeno Provedor de Acesso Internet de acesso gratuito chamado Chester County InterLink (CCIL) em West Chester, Pensilvânia (eu fui cofundador do CCIL e escrevi nosso software multiusuário de BBS - você pode observá-lo executando um telnet para locke.ccil.org. Hoje suporta quase três mil usuários em trinta linhas.) 

O trabalho permitiu-me o acesso 24 horas por dia à rede através da linha de 56K do CCIL - de fato, praticamente exigiu! Consequentemente, eu fiquei acostumado a acesso instantâneo ao correio Internet. Por razões complicadas, era difícil fazer o SLIP funcionar entre minha máquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, achei incômodo ter que executar telnet periodicamente para o locke para verificar meu correio.

O que eu queria era que ele fosse enviado para o snark de modo que eu fosse notificado quando uma mensagem chegasse e pudesse manuseá-lo usando todas as minhas ferramentas locais. O simples reenvio do sendmail não funcionaria, porque minha máquina local não está sempre na rede e não tem um IP estático. O que eu precisava era um programa que pegasse meu correio através da conexão SLIP e o entregasse localmente. 

Eu sabia que tais programas existiam, e que a maioria deles usava um protocolo de aplicação simples chamado POP (Post Office Protocol). E, realmente, já havia um servidor POP3 incluído com sistema operacional BSD/OS do locke. Eu precisava de um cliente POP3. Então eu procurei na Internet e encontrei um. Na verdade, eu encontrei três ou quatro. 

Eu usei o pop-perl por algum tempo, mas faltava o que parecia uma característica óbvia, a habilidade de alterar os endereços no correio recebido para que as respostas fossem enviadas corretamente. O problema era este: suponha que alguém chamado `joe' no locke tenha me enviado uma mensagem. Se eu capturasse o correio para o snark e tentasse então lhe responder, meu programa de correio tentaria alegremente enviá-lo a um `joe' inexistente no snark.

Editar manualmente os endereços de resposta para adicionar '@ccil.org' rapidamente tornou-se um tormento. Isto era claramente algo que o computador teria que fazer para mim. Mas nenhum dos clientes POP existentes sabiam como! E isto nos traz à primeira lição: 

1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador. 

Talvez isto deveria ter sido óbvio (um antigo provérbio diz que "necessidade é a mãe da invenção'') mas muitas vezes os programadores gastam seus dias buscando retorno em programas que eles não necessitam nem gostam. Mas não no mundo do Linux - o que pode explicar porque a qualidade média do software originada na comunidade de Linux é tão alta. 

Assim, eu me lancei imediatamente com o ímpeto de codificar um novo cliente POP3 para competir com os
existentes? De maneira alguma! Eu olhei com cuidado os utilitários POP que eu tinha à
disposição, perguntando-me "qual deles é o mais próximo do que eu quero?''. Porque... 

• 2 - Os programadores bons sabem o que escrever. O grandes sabem o que reescrever (e reusar).

Embora eu não me considere um grande programador, eu tento me passar por um. Uma importante característica dos grandes é a preguiça construtiva. Eles sabem que você ganha um 'A' não por esforço, mas por resultados, e é quase sempre mais fácil partir de uma boa solução parcial do que do nada; não tentou realmente escrever Linux do nada. Ao contrário, ele começou reusando código e idéias do Minix, um pequeno sistema operacional Unix-like para máquinas 386. Eventualmente todo o código Minix se foi ou não completamente reescrito - mas quando estava lá, forneceu as bases para o infante que se transformaria no Linux. 

Com o mesmo pensamento, eu fui procurar um utilitário POP que fosse razoavelmente bem codificado, para usar como uma base de desenvolvimento. A tradição do mundo Unix de compartilhar o código fonte foi sempre amigável para a reutilização de código (esta é a razão porque o projeto de GNU escolheu o Unix como sistema operacional base, apesar das sérias reservas sobre o mesmo). 

O mundo Linux tem levado esta tradição quase a seu limite tecnológico; tem terabytes de códigos abertos amplamente disponíveis. Assim gastando tempo procurando algum software quase-bom-o-bastante feito por alguém é mais provável dar a você mais bons resultados no mundo Linux do que em qualquer outro lugar. 

Algumas semanas mais tarde, entretanto, eu tropecei pelo código do 'popclient' desenvolvido por Carl Harris, e descobri que eu tinha um problema. Embora o fetchpop tenha tido algumas idéias boas e originais (tal como o modo daemon), podia somente trabalhar com POP3 e foi codificado de uma maneira um tanto amadora (Seung-Hong era um programador brilhante porém inexperiente, e ambas as características ficaram evidentes). 

O código de Carl era melhor, bastante profissional e sólido, mas em seu programa faltou diversas características importantes e complicadas de serem implementadas do fetchpop (incluindo aquelas que eu implementei). 

Ficar ou trocar? 

Se eu trocasse, eu estaria jogando fora o código que eu já havia feito em troca de uma base melhor do desenvolvimento. Um motivo prático para trocar era a presença de suporte para vários protocolos. POP3 é o protocolo mais comumente utilizado de todos os protocolos de correio dos servidores, mas não o único. 

Fetchpop e os outros concorrentes não faziam POP2, RPOP ou APOP, e eu estava realmente tendo alguns pensamentos de talvez adicionar ou Protocolo de Acesso a Mensagem da Internet, o mais recente e poderoso protocolo de correio desenvolvido) só para me divertir. Mas eu tinha uma razão mais teórica para pensar que trocar seria uma boa idéia, alguma coisa que eu aprendi muito antes do Linux: 

• 3. "Planeje jogar algo fora; você irá, de qualquer maneira.'' (Fred Brooks, "The Mythical Man-Month'', Capítulo 11) 

Ou, colocando de outra forma: 

1. Você freqüentemente não entende realmente o problema até depois da primeira vez que você implementa uma solução. 
2. Na segunda vez, talvez você saiba o suficiente para fazer corretamente. 
3. Então se você quer fazer algo certo, esteja preparado para começar tudo novamente pelo menos uma vez. 

Bem (eu disse para mim mesmo) as mudanças no fetchpop foram a minha primeira tentativa. Então eu troquei. Depois que eu mandei meu primeiro conjunto de alterações para Carl Harris em 25 de junho de 1996, eu percebi que na verdade ele perdera o interesse pelo popclient há algum tempo até então. 

O código era um pouco empoeirado, com pequenos erros. Eu tinha muitas mudanças para fazer, e nós rapidamente concordamos que o lógico para eu fazer era tomar conta do programa. Sem perceber, o projeto havia se intensificado. Eu não estava mais contemplando somente pequenos consertos para um cliente POP existente. Eu estava mantendo um cliente completo, e havia idéias borbulhando na minha cabeça que eu sabia iriam provavelmente levar a importantes mudanças. Em uma cultura de software que encoraja a troca de código, isto é um caminho natural para um projeto evoluir. Eu estava representando isto: 

• 4. Se você tem a atitude certa, problemas interessantes irão encontrá-lo. 

Mas a atitude do Carl Harris foi ainda mais importante. Ele entendeu que: 

• 5. Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente. 

Sem ao menos ter que discutir isso, Carl e eu sabíamos que nós tínhamos um objetivo em comum de ter a melhor solução disponível. A única questão para nós foi se eu poderia me estabelecer como um par de mãos seguras para isso. Uma vez que eu tenha feito isso, ele agiu com cortesia e rapidez. Eu espero que eu aja assim quando chegar a minha vez. (...)


Outros tópicos que autor desenvolve na obra, igualmente importantes:


3. A importância de ter usuários: 

• Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz.

4. Libere cedo, libere freqüentemente:

• Liberece cedo. Libere freqüentemente. E ouça seus fregueses
• 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.

5. Quando uma rosa não é uma rosa:

• Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. Brooks, Capítulo 11: "Mostre-me seu código e esconda suas estruturas de dados, e eu poderei continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não necessitarei do seu código; ele será óbvio .''
• Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso.

6. Popclient transforma-se em Fetchmail:

• A melhor coisa depois de ter boas idéias é reconhecer boas idéias dos seus usuários.
• Freqüentemente, as soluções mais impressionantes e inovadoras surgem ao se perceber que o seu conceito do problema estava errado.
• "A perfeição (em projetar) é alcançada não quando não há mais nada a adicionar, mas quando não há nada para jogar fora.''

7. Fetchmail cresce:

• Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta verdadeiramente *boa* leva ela própria a usos que você nunca esperou.
• Quando escrevendo um software gateway de qualquer tipo, faça tudo para perturbar o conjunto de dados o menos possível - e *nunca* jogue fora informação a não ser que o destinatário force você a isto!

8. Algumas lições a mais do Fetchmail:

• Quando sua linguagem não está perto de um Turing completo, açúcar sintático pode ser seu amigo.
• Um sistema de segurança é tão seguro quanto é secreto.

9. Pré-condições necessárias para o estilo Bazar:

• Um coordenador ou líder de um projeto no estilo bazar deve ter boa habilidade de comunicação e relacionamento. Isto deve parecer óbvio. 
• Para construir uma comunidade de desenvolvimento, você precisa atrair pessoas, fazer com que se interessem no que você está fazendo, e mantê-las alegres sobre a quantidade de trabalho que estão fazendo. 
• O entusiasmo técnico constitui uma boa parte para atingir isto, mas está longe de ser toda história. 
• A personalidade que você projeta também importa. Não é uma coincidência que Linus é um rapaz gentil que faz com que as pessoas gostem dele e que o ajudem.

10. O contexto social do código aberto:

• Para resolver um problema interessante, comece achando um problema que é interessante para você.
• Contraponto à Lei de Brooks: "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".

Eric Raymond conclui, no trabalho, 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."

Fonte: RAYMOND, Eric. A Catedral e o Bazar

* (Cópia e redistribuição permitida sem royalty contanto que esta notificação esteja preservada)