Há mais de cinqüenta anos, Grace Hoper
usou de sua experiência em programar o UNIVAC (Universal
Automatic Computer) com a linguagem “flowmatic” –
aliás, um projeto de software livre – e escreveu o
primeiro compilador. A era da computação moderna
começou. O UNIVAC foi o primeiro computador totalmente
projetado para fins comerciais. A primeira versão foi usada
em 1952 pela rede americana de TV CBS em pesquisas eleitorais.
Alguém poderia dizer que as coisas não melhoraram
muito desde aquele dia.
Os programadores e analistas de sistema foram os
últimos a utilizar o computador para auxiliar em suas próprias
tarefas profissionais. Programadores, lá no fundo, consideram-se
artistas e são avessos a regras de quaisquer tipos, sejam
de estilo, sejam de padrões de programação.
Mesmo com os progressos ocorridos – como as
OOP (Object Oriented Languages), AI (Artificial Inteligence),
UML (Unified Modeling Language), Workbenches de Programação,
CMMI (Capability Maturity Model Integrated) etc. –, a arte
de mapear os processos reais em sistemas computacionais continua
extremamente personalista.
O NIST(National Institute of Standards and Technology)
dos EUA estima que em 2001 cerca de US$ 59 bilhões, ou
cerca de 0,6% do PIB americano, foi perdido por causa dos erros
(bugs) de software. O SCC (Sustainable Computing Consortium),
uma iniciativa de escolas, governo e empresas privadas para direcionar
aperfeiçoamentos da TI estima que este valor é apenas
a parte “de baixo” do gráfico. O custo real dos
defeitos em sistemas nas companhias americanas deve somar pelo
menos US$ 200 bilhões, de acordo com o SCC.
Dificilmente passa uma semana sem que um importante
bug de software ou um buraco na segurança de algum sistema
não seja reportado na imprensa. Como diz George Tassey,
o economista sênior responsável pelo Relatório
do NIST, “o software está muito acima dos outros produtos
industriais, em termos de erros e bugs, quando é comercializado”.
Jin Laruf, pesquisador sênior da Microsoft
Research, concorda: “Nós estamos escrevendo software
há cerca de 50 anos e ainda produzimos um produto com grande
numero de erros e bugs. As ferramentas de trabalho tornaram-se
muito melhores, mas a qualidade do código gerado não
reflete isso necessariamente”.
Uma regra de polegar geralmente aceita diz que
são necessários US$ 10 para corrigir um bug durante
o desenvolvimento do projeto; US$ 100 para corrigi-lo durante
o processo de Controle de Qualidade (QA- quality assurance); US$
1.000 para a correção durante o beta teste; e US$
10.000 ou mais para corrigir um bug num sistema em produção.
Por que se desperdiça tanto tempo e dinheiro?
Jim Johnson, diretor do Standish Group, empresa especializada
em planejar e avaliar investimentos em TI, diz que isto se deve
ao fato de que “a Microsoft nos ensinou que não tínhamos
como escapar dos erros de código, éramos obrigados
a conviver com eles. Da metade dos anos 90 até 2000, a
programação foi geralmente muito descuidada. Agora
há uma pressão maior por qualidade vinda dos usuários
que sentiram o real custo dos bugs para suas empresas.”
Com freqüência, sistemas são
desenvolvidos precipitadamente, somente para atender a cronogramas
apertados e irreais, e a correção dos bugs é
normalmente aceita como parte do processo de suporte técnico.
Talvez não seja um ensinamento da Microsoft, mas com certeza
é uma combinação dos fatores mencionados
por Johnson e a característica proprietária do software.
Avaliação constante
Acredita-se que a principal razão pela qual
o software livre é melhor e mais seguro é justamente
o fato de haver mais olhos treinados avaliando o código.
Há muito mais chances de alguém encontrar um problema.
Não necessariamente alguém será
remunerado por fazer isso ou terá a sua avaliação
de performance afetada. Como apontou Eric Raymond em seu clássico
“The Cathedral and the Bazaar”, não é
nenhum desses fatores que normalmente motivam os programadores
de sistemas com o código aberto. Ao invés disso,
eles são motivados pela busca da excelência e pelo
reconhecimento de seus pares (a comunidade). O estilo de trabalho
do software aberto acelera a avaliação do código
e a descoberta de erros. Além disso, embora pouco divulgado,
os programadores aceitos para contribuir com os sistemas de código
aberto seguem normas e padrões rígidos de estilo
e programação, exercendo uma grande disciplina.
Caso contrário, seu código não será
aceito pela comunidade para ser incorporado ao sistema.
Para entender o porquê da maior eficácia
na criação e correção do código
livre, vale recorrer à explanação de Eric
Raymond: “No informe de erros, os usuários de código
fechado normalmente reportam apenas sintomas superficiais. Assim,
são omitidos dados de background e raramente é incluída
uma receita para replicar o problema apontado. O problema não
aparente é a diferença entre os modelos mentais
de quem testa e de quem programa. Este, de dentro, olha para fora,
e o outro, de fora, olha para dentro, tentando compreender o incompreensível.
Isso pode causar muita frustração a ambos os lados”.
O modelo de desenvolvimento com fontes abertas
quebra este cliclo fechado, pois ambos os parceiros compactuam
a mesma visão dos fatos e podem comunicar-se efetivamente
sobre deles. Não existe programa de beta teste para sistemas
de código fechado que possa duplicar esse modelo. Por isso,
devido à rapidez na correção de bugs e no
atendimento a padrões, inclusive de segurança, o
programa de código aberto é inerentemente mais seguro
que o de código fechado.
Para uma empresa, representa um valor inestimável
possuir um sistema que ela pode alterar, modificar ou ainda corrigir,
sem depender da boa vontade ou capacidade de outros. Tudo isso
sem gastar nada, ou quase nada.
Sugestão para uma arte: Por que o Linux
é mais seguro?
01. Porque
é mais testado. Mais olhos podem perceber as minúcias
de como o sistema é feito. Por estar aberto, está
mais exposto em um primeiro momento. Observa-se a falha e esta
é corrigida imediatamente.
02. Não existem vírus
para o LINUX.
03. O LINUX não permite
programas auto-executáveis.
04. A concepção
do sistema operacional, em sua arquitetura, contempla a restrição
de privilégios por usuário, restringindo a execução
de tarefas não-privilegiadas.
05. Facilidade de customização
voltada para a função-alvo. Você pode dar
mais atenção aos aspectos de segurança dos
recursos envolvidos, sem se preocupar com o restante.
06. Está de conformidade
com os Standards. E as Best Practices estão configuradas
e são geradas e reavaliadas permanentemente por uma grande
comunidade de usuários e desenvolvedores.
07. Permite a escolha entre
várias ferramentas diferentes para executar o mesmo trabalho.
Por exemplo, Scripts: Bash, VI (editor), Perl.
08. Pode-se utilizar diferentes
ferramentas de administração e implementação
de serviços. Ex: Sendmail, Postfix, e Qmail, para Correio.
Squirrel e IMPE com Horde, como WEB Mail.
09. O Kernel processa em
modo protegido. As aplicações rodam em outras instâncias
e áreas de memória. Por isso, pode-se colocar ou
retirar a disponibilidade de aplicações a qualquer
10. Tudo é um serviço.
Este é chamado quando necessário, instancionado,
retirado e reativado sem afetar o Kernel.
11. A segurança pode
ser vista sob outros ângulos, como o da disponibilidade
–- HD (HA – High Availability) – Alta disponibilidade;
HP–High Performance Alto poder de processamento; Cluster
Beowolf; Grid – Poder de distribuição da aplicação.
* Marco Bueno é diretor da Utah Linux Center,
de São Paulo