Boa noite povo!
No último versículo: quinta parte da tradução de “The Cathedral and the Bazaar”. Agora a sexta.
Lance Antecipadamente, Lance Frequentemente
Lançamentos antecipados e frequentes são uma parte crítica do modelo de desenvolvimento do Linux. A maioria dos desenvolvedores (inclusive eu) costumava acreditar que essa era uma política ruim para projetos maiores do que os triviais, porque versões iniciais são quase que por definição versões com bugs e você não quer desgastar a paciência de seus usuários.
Compre seu Ingresso Agora
Essa crença reforçou o compromisso geral com um estilo de desenvolvimento da construção do tipo catedral. Se o objetivo primordial era que os usuários vissem o mínimo possível de bugs, por que então você só lançaria uma versão a cada seis meses (ou com menos frequência) e trabalharia como um cão na depuração entre os lançamentos. O núcleo Emacs C foi desenvolvido desta forma. A biblioteca Lisp, na verdade, não era – porque havia arquivos Lisp ativos fora do controle da FSF, onde você poderia encontrar novas versões de códigos de desenvolvimento, independentemente do ciclo de lançamento do Emacs. [QR]
O mais importante deles, o arquivo Emacs Lisp da Ohio State, antecipou o espírito e muitos dos recursos dos grandes arquivos Linux atuais. Mas poucos de nós realmente pensaram muito sobre o que estávamos fazendo, ou sobre o que a própria existência daquele arquivo sugeria sobre problemas no modelo de desenvolvimento da construção do tipo catedral da FSF. Fiz uma tentativa séria por volta de 1992 para obter um monte do código de Ohio formalmente fundido na biblioteca oficial do Emacs Lisp. Eu me deparei com problemas políticos e foi em grande parte mal sucedido.
Mas, um ano depois, quando o Linux se tornou amplamente visível, ficou claro que algo diferente e muito mais saudável estava acontecendo ali. A política de desenvolvimento aberto de Linus era o oposto da construção-catedral. Os arquivos de Internet do Linux estavam em expansão, várias distribuições estavam sendo lançadas. E tudo isso foi impulsionado por uma frequência inédita de lançamentos do sistema principal.
Linus estava tratando seus usuários como co-desenvolvedores da maneira mais eficaz possível:
- Lance antecipadamente. Lance frequentemente. E ouça seus clientes.
A inovação de Linus não foi tanto em fazer lançamentos rápidos, incorporando muito feedback do usuário (algo como isso já era tradição do mundo Unix por um longo tempo), mas em escalar isto até um nível de intensidade que combinava com a complexidade do que ele estava desenvolvendo. Naqueles tempos antigos (por volta de 1991) não era desconhecido para ele lançar um novo kernel mais de uma vez por dia! Como ele cultivou sua base de co-desenvolvedores e aproveitou a Internet para colaboração mais do que qualquer outra pessoa, isso funcionou.
Mas como isso funcionou? E foi algo que eu poderia duplicar ou contava com algum gênio único como Linus Torvalds?
Eu não penso assim. Claro, Linus é um ótimo hacker. Quantos de nós poderíamos projetar todo um kernel do sistema operacional com qualidade de produção a partir do zero? Mas o Linux não representou nenhum salto conceitual impressionante. Linus não é (ou pelo menos, ainda não) um gênio inovador do design da mesma forma que, por exemplo, Richard Stallman ou James Gosling (da NeWS e da Java). Em vez disso, Linus me parece ser um gênio de engenharia e implementação, com um sexto sentido para evitar bugs e becos sem saída de desenvolvimento e um verdadeiro talento para encontrar o caminho de esforço mínimo do ponto A ao ponto B. De fato, todo o design do Linux respira essa qualidade e espelha a abordagem de projeto essencialmente conservadora e simplificadora de Linus.
Então, se lançamentos rápidos e alavancar o ambiente da Internet ao máximo não fossem acidentes, mas partes integrantes da visão genial de engenharia de Linus sobre o caminho do esforço mínimo, o que ele estava maximizando? O que ele estava produzindo do maquinário?
Posto assim, a questão responde a si mesma. Linus estava mantendo seus hackers/usuários constantemente estimulados e recompensados – estimulados pela perspectiva de ter uma parte da ação satisfatória do ego, recompensada pela visão de melhorias constantes (até diárias) em seu trabalho.
Linus estava objetivando diretamente maximizar o número de pessoas-horas jogadas em depuração e desenvolvimento, mesmo com o possível custo de instabilidade no código e esgotamento da base de usuários se qualquer bug sério se mostrasse intratável. Linus estava se comportando como se acreditasse em algo assim:
- Dada uma base suficientemente grande de beta-testers e co-desenvolvedores, quase todos os problemas serão caracterizados rapidamente e a correção será óbvia para alguém.
Ou, menos formalmente, “Com olhos suficientes, todos os erros são superficiais”. Eu chamo isso de “Lei de Linus”.
[QR] Exemplos de desenvolvimento bem-sucedido de código aberto e bazar anteriores à explosão da Internet e não relacionados às tradições Unix e Internet existiram. O desenvolvimento do utilitário de compactação info-zip durante 1990 – x1992, principalmente para máquinas DOS, foi um desses exemplos. Outro foi o sistema de quadros de avisos do RBBS (novamente para DOS), que começou em 1983 e desenvolveu uma comunidade suficientemente forte que houve lançamentos bastante regulares até o presente (meados de 1999) apesar das enormes vantagens técnicas do correio da internet e compartilhamento de arquivos sobre os BBSs locais. Enquanto a comunidade de info-zip dependia, até certo ponto, do correio da Internet, a cultura de desenvolvedores do RBBS era realmente capaz de basear uma comunidade on-line substancial no RBBS que era completamente independente da infra-estrutura do TCP/IP.
Terminada a parte 6, amanhã a sétima.
