Esses últimos dias comecei a ler o ensaio de Eric Raymond chamado a Catedral e o Bazar. Para quem não sabe, Eric Raymond é uma das pessoas mais ativas em produção de software livre. Já contribuiu com o EMacs, NetHack , nCurses (biblioteca para o desenvolvimento de Interfaces em modo texto) e é mantenedor do Fetchmail (programa que baixa e envia emails usando protocolos como POP, IMAP, SMTP e etc).
Neste artigo, Eric Raymond fala muito sobre a produção de software livre, derruba alguns mitos sobre a criação do Kernel do Linux, e conta exemplos de coisas que aconteceram durante a produção. Colocarei nesse artigo algumas observações minhas sobre esse artigo.
Produção de Software
Produzir software está longe de ser uma tarefa trivial
Para atingir níveis altos de confiabilidade e satisfação dos usuários costumam ser coisas bem raras. Bugs costumam ser frequentes e praticamente nunca vi um software que não necessitasse de atualizações ou patchs de segurança. Além do mais, nesse mundo tão dinâmico, a cada dia exigências mudam. bibliotecas novas aparecem, protocolos diferentes aparecem. Aí vem a questão: Será que conseguimos produzir um software, com um nível alto de qualidade, que acompanhe esse ritmo ?
O TeX desenvolvido por Knuth, e a dupla gcc/Emacs inicialmente desenvolvidos por Stallman, são raras exceções de programas de alto nível desenvolvidas por uma pessoa só.O TeX é utilizado em larga escala no mundo acadêmico, o gcc é um compilador muito utilizado e o Emacs é um editor muito popular. Mas esses dois são pessoas de um nível extraordinário. Algo como um Pelé ou um Picasso em suas respectivas áreas.
Mas o mundo é feito, em sua grande maioria, de pessoas normais, que construíram muitos e muitos softwares utilizando o que eles tinham de mais precioso: Seus usuários. São eles que sugerem alterações, comunicam bugs e são eles que fazem seu trabalho valer a pena. Aí vale um ponto para o software livre: Vamos supor que você não goste de algo em um software produzido por uma grande empresa. O que você faria ? Poderia tentar fazer alguma reclamação. Se por meios eletrônicos: Não acho que sua reclamação iria direto para a equipe de programadores antes de passar por muitas e muitas triagens. Se por meios telefônicos: Você provavelmente ligaria para uma central de pessoas que não estão preocupadas em anotar sugestões mas sim em resolver problemas de natureza de suporte técnico. Se por meios pessoais: você chegaria a uma portaria de uma empresa e não te deixariam subir.
Mas e se fosse um software livre ? Os desenvolvedores costumam publicar seus emails. Você pode enviar um email com sugestões, críticas, reclamações ou entrar em uma lista de discussões do software que você será ouvido. Por telefone acho dificil você falar com qualquer um deles. Mas muitos são os eventos de software livre e essas pessoas realmente participam dessas coisas. Você pode em algum deles ir conversar com eles. Essas pessoas costumam ser bem simpáticas e realmente vão te ouvir, pois sabem que você é um bem muito precioso.
Ouvir os pedidos dos teus usuários é estar sempre ligado em novas idéias. em novas sugestões e principalmente em novos bugs que seu programa pode ter. Assim você pode corrigi-los ou até esperar algum outro desenvolvedor te enviar uma correção. Isso é uma das grandes vantagens do código aberto, outros desenvolvedores podem trablhar no desenvolvimento do software e te ajudar.Como desenvolvedores, podem sugerir alterações e correções no código o que pode solucionar muitos bugs.
Lei de Linus
Uma lei muito conhecida na engenharia de software é a lei de Brooks “Adicionando pessoas a um projeto de software atrasado só atrasa-o ainda mais”.
Como softwares têm uma construção muito complexa, a cada pessoa que se inclui em um projeto de software é necessário ensiná-la a trabalhar no projeto temporariamente diminuindo a produtividade de alguns programadores. Outro argumento é que a comunicação aumentaa quadraticamente. Ao dobrar o número de programadores você quadruplica o número de conversas acerca do software. Se múltiplas pessoas estão fazendo o mesmo projeto, então é necessário manter tudo sincronizado, pois pode-se gastar mais tempo descobrindo o que se precisa fazer.
Uma lei destas com certeza poderia decretar o fim das produções de software livre. Existem projetos com milhares de pessoas trabalhando, o que poderia ser feito ?
Um software geralmente tem um core e um halo. Chama-se de core as coisas essenciais para ele funcionar, e o halo é todo o resto. O core é o essencial para ele funcionar (geralmente pequeno),o Halo são coisas extras que o tornam mais fácil de se utilizar (geralmente enorme), adicionam funcionalidades extras e etc. Geralmente o core é desenvolvido por poucas pessoas (frequentemente um, ocasionalmente até três) e o halo por muitas pessoas (geralmente centenas).
O core segue um desenvolvimento mais cuidadoso pelos poucos desenvolvedores que trabalham nele. O funcionamento do software depende do core.
Como o halo de um software é muito variado e muito grande, dificilmente dois desenvolvedores farão trabalho repetido e precisarão se comunicar com poucas pessoas (que desenvolvem a mesma funcionalidade), e por não ser essencial para o funcionamento, os bugs serão frequentes. O que não é tanto problema: geralmente há da ordem de centenas de beta-testers que os apontarão. E com uma política de muitos releases, os desenvolvedores poderão arrumar o código apenas pouco tempo depois de o terem feito.
Bugs não são coisas tão problemáticas em um software livre. Com muitos beta-testers, há muitos relatórios de falhas e com muitos olhos depurando o código, é apenas questão de (pouco) tempo achar aonde (exatamente a linha, ou função) que está o bug no software. Deste modo “todos os erros são triviais” (lei de Linus).
Uma solução nada simples e que refuta o fato que as produções de software livre são “torres de babel”.
Links
