[GUFSC] Quem paga a conta do software livre?

[Rafael R Obelheiro]

[ Apesar de ser do ano passado, nao me lembro de ver este artigo por
  aqui. Ainda que nao conte grandes novidades, achei bastante
  interessante.  --rro ]


[http://webinsider.uol.com.br/vernoticia.php/id/1946]

26/10/2003
Quem paga a conta do software livre?

  Há quem pense que software livre é diletantismo. Não é bem assim,
  muita gente escreve software de 9 às 6, às vezes até de gravata, em
  empresas públicas e privadas. Entenda porque.

Ricardo Bánffy


Outro dia, em uma palestra na Assembléia Legislativa sobre o uso de
software livre na administração pública, eu ouvi, pela ducentésima
vez, alguém perguntar de onde, afinal, vem o dinheiro para custear o
desenvolvimento de tantos programas.

Não fiquei surpreso por ouvir a pergunta. Mas fiquei muito surpreso
que as primeiras respostas não dessem conta de alguns fatos
importantes. Me senti compelido a pedir o microfone à mesa e colocar,
eu mesmo, por terra os temores do meu colega.

Esta é uma das perguntas clássicas que pessoas inocentes ou
mal-intencionadas adoram fazer. Eu prefiro acreditar que este rapaz
(devia ter mais ou menos a minha idade, logo, vou chamá-lo de rapaz)
era do primeiro grupo, embora ele estivesse cercado de pessoas que
faziam, evidentemente, parte do segundo.

Uma noção errada que muita gente ainda tem é de que software livre é
feito nas horas vagas de profissionais que, depois de voltar pra casa
do trabalho, fazer jantar, levar o cachorro passear e colocar os
filhos para dormir, ainda encontra tempo para escrever software.

Bom... Não quero desmerecer estes heróis, mas eles não estão sozinhos.

Muita gente escreve software livre das 9 às 6. Alguns, inclusive, usam
gravata.Mas que coisa feia... Essas pessoas, sendo pagas por seus
empregadores, ficam brincando de fazer software que depois vão dar
pros outros?

Não é bem isso. Para responder esta pergunta, eu vou citar alguns
exemplos.

O produto que quase servia. Algum tempo atrás, trabalhando na empresa
de um amigo, havia um cliente que tinha a necessidade de autenticar os
usuários da sua intranet contra um domínio em um servidor Windows NT.
É uma necessidade comum.

O cliente, um banco internacional, tinha optado por construir sua
intranet com um servidor de aplicações chamado Zope (do qual eu gosto
bastante, como evidencia o "powered by" que permeia meu site).
Localizamos um componente para o Zope que permitiria fazer exatamente
isto (e mais um monte de outros truques que não vêm ao caso agora).
Mas havia um problema.

No primeiro teste na rede do banco, o componente não funcionou.
Examinando o código-fonte dele, descobrimos que ele não funcionaria
por motivos relacionados à arquitetura da própria rede do banco (e que
não seria, de forma alguma, modificada). Conversamos e decidimos que o
caminho mais fácil seria arrumá-lo. Algumas horas depois, conversando
com o "dono" do projeto via IRC (ele vive na Austrália), dois de nós
se tornaram colaboradores "oficiais" (nossos nomes estão na página do
produto [url=http://sourceforge.net/projects/exuserfolder/]).

Poucos dias depois, não só o problema da autenticação estava
resolvido, como o produto tinha tido melhoras muito expressivas em seu
desempenho com a implementação de várias otimizações. E nós nem mesmo
precisamos desvendar os becos escuros do Windows por onde é feita a
autenticação.

Resumindo: Melhorar um produto de terceiros tornou possível entregar,
rapidamente, uma solução que atendia as necessidades do cliente. Como
um efeito colateral, outras empresas que criam soluções baseadas em
Zope têm uma opção melhor para integrar suas aplicações às redes
Windows dos seus clientes. Se ninguém tivesse precisado da
funcionalidade, ela não teria sido implementada ou permaneceria
minimamente funcional, exatamente como a encontramos. A necessidade, e
não as forças do mercado, guiam a evolução do software livre.

Os outros exemplos não são em primeira mão, mas ilustram outras formas
de se usar software livre.

Tenho caixas para vender. Lá por 2000, a IBM tomou conhecimento de
três coisas. Primeiro: ela não tinha uma solução Unix muito boa em
termos de preço/performance. Isso estava fazendo com que concorrentes,
entre eles a Sun, levassem clientes embora.

Segundo: eles tinham servidores baratos, poderosos, baseados em
hardware Intel, que poderiam reverter isso, se, ao menos, a IBM
tivesse um sistema operacional Unix-like para colocar neles.

Terceiro: eles dependiam da Microsoft para fornecer o único sistema
operacional disponível para toda a linha de servidores Intel. Isto é,
eles dependiam da mesma empresa que era parceira no desenvolvimento do
OS/2 e que lançou um produto, o Windows 3, para concorrer justamente
com o OS/2. Que Deus o tenha.

Nas palavras da IBM (eu uma vez conversei com um VIP responsável pelos
esforços de Linux da IBM - ainda estou procurando o cartão dele), em
2000, o Linux não estava bom o bastante para aplicações críticas. Foi
quando eles decidiram que, em vez de portar novamente o AIX para Intel
(existiu uma versão dele que rodava nos PS/2 mais parrudos), eles
investiriam recursos para tornar o Linux "enterprise-ready".

Trocando em miúdos, a IBM achou que o mercado de sistemas operacionais
proprietários para PCs estava morto (a Microsoft consome todos os
recursos desse "ecossistema") e que não valeria a pena investir num
AIX/x86 quando, por menos dinheiro, eles poderiam ajudar a deixar o
Linux capaz de atender às demandas dos clientes.

Brigas judiciais à parte (a SCO, ex-Caldera, acha que a IBM roubou
código e usou "métodos proprietários" dela para colocar no Linux), a
IBM fez várias contribuições de código para o kernel e drivers do
Linux em áreas importantes como escrita em discos e suporte a
multi-processamento com acesso não-uniforme à memória (que tinha sido
desenvolvido por uma empresa que a IBM comprou, a Sequent,
especializada em computadores com dúzias de processadores).

A IBM também fez e bancou vários estudos sobre como o uso de
servidores Intel rodando Linux é economicamente vantajoso em relação
ao emprego de máquinas RISC rodando versões proprietárias de Unix
(inclusive os pSeries da própria IBM). Debaixo da mesma bandeira,
favoreceu o desenvolvimento de versões do Linux para seus mainframes.

Resumindo: ao investir (junto com outras empresas) no desenvolvimento
do Linux, a IBM conseguiu várias vitórias importantes. Ela agora tem
uma linha de servidores Linux de baixo custo competindo com enormes
vantagens com soluções RISC dos seus concorrentes e mesmo com
servidores baseados em Windows.

A IBM é o único produtor de mainframes reportando crescimento das
vendas no segmento, com empresas consolidando dezenas de servidores
menores em um único equipamento. Como um efeito colateral disso, o
kernel do Linux deu um salto impressionante de qualidade.

Onde, anos atrás, eu teria que instalar um Windows, eu hoje posso usar
um sistema operacional moderno e modular, que usa um kernel firme como
uma rocha (minha máquina de desenvolvimento detém o meu recorde
doméstico de 61 dias sem um boot - quebrado não por um crash, mas por
uma falta de energia), com discos que não perdem dados quando a
energia falha (graças ao journal), com excelente suporte a máquinas
com mais de um processador (que, infelizmente, não é meu caso) e que
não serve como meio de cultura para pragas digitais como o Blaster ou
Slammer. E ela ainda encontra tempo para registrar pelo menos umas 30
tentativas de contágio por worms a cada dia.

Uma caixa nova. Na mesma linha de raciocínio, Intel e HP perceberam
que lançar o processador Itanium no mercado sem um suporte expressivo
de software aplicativo seria suicídio. Em vez de pedir gentilmente à
Microsoft (na verdade, eles gastaram bastante dinheiro mandando
programadores deles para ficarem dentro da Microsoft ajudando no
trabalho) que portasse o Windows para o Itanium (lição de história: a
falta de aplicativos e de suporte do Windows foi o último prego no
caixão dos processadores MIPS, PowerPC - em PC-likes- e Alpha) e rezar
para que ele estivesse pronto ao mesmo tempo em que o processador
fosse lançado, a HP decidiu apostar em mais dois cavalos extras.

Um deles, o port do HP/UX (o Unix proprietário da HP) para o Itanium
e, em outra, no port do Linux para o processador. Com um processador
de 64 bits no mercado há algum tempo, a HP hoje pode vender suas
soluções com uma escolha maior de sistemas operacionais em vários
mercados que não estariam acessíveis não fosse essa decisão.

Hoje a HP vende os equipamentos HP/UX sobre Itanium aos seus clientes
HP/UX tradicionais, vende máquinas Itanium rodando Windows para seus
clientes Windows e vende máquinas Itanium rodando Linux para os
clientes que preferem Linux. E, claro, vendem máquinas Intel também.

Debaixo do chão. Outro caso bem interessante é o do Metrô de São
Paulo. O Metrô já tinha trocado um sistema de e-mail corporativo
baseado em mainframe por um construído com software livre quando
decidiu economizar dinheiro usando StarOffice (naquela época a Sun não
cobrava por ele) em vez do Microsoft Office.

Eles tinham dois problemas: O primeiro deles era que não existia
documentação, material didático ou tutoriais em português para o
produto. Para resolver isto, o Metrô contratou uma empresa para ajudar
na preparação da documentação e dos treinamentos.

O segundo problema era o do idioma: Existia uma versão do
StarOffice/OpenOffice em português, mas era o português de Portugal.

A solução, no entanto, não veio do Metrô. Um engenheiro químico de
Rondonópolis, Cláudio Ferreira Filho, decidiu coordenar a tradução do
OpenOffice, que acabou, inclusive, sendo concluída antes que a Sun
conseguisse lançar o StarOffice 6 em português.

No final das contas, mesmo investindo dinheiro para modificar e
complementar uma oferta existente, a economia feita em licenças não
compradas de Microsoft Office mais do que cobriu os investimentos no
produto livre. Pode não ser muito vantajoso se você tem um escritório
com cinco pessoas, mas para eles, com mais de 1000 desktops por toda a
companhia, a decisão foi acertadíssima.

E o resto, de onde vem tudo isso?. Você pode imaginar que, sem uma
estrutura de investimentos pesada, nenhum produto de software tem
condições de se desenvolver. Todos os exemplos que eu citei envolvem
empresas enormes.

Nós vimos o passo de lesma com que o software tem evoluído nos últimos
30 anos. Janelas, mouse, display bit-mapped e letras pretas em fundo
branco foram transformados na GUI moderna que ainda nos serve, no
centro de pesquisas de Palo Alto, da Xerox, no meio da década de 70.
Hoje eu tenho mais cores e mais botões no mouse. E não muito mais do
que isso.

Meu micro desktop continua travando de vez em quando. Em semanas eu
devo reformatar a máquina e deixá-la limpa outra vez - com seis meses
na minha mão, qualquer Windows precisa ser reinstalado do zero.

O que o software livre tem que o software proprietário não tem e que
pode resolver isso? Na verdade é o contrário. O software livre não tem
uma coisa.

Duplicação de esforço. Quando uma empresa de software proprietário
desenvolve, digamos, um editor de textos, ela guarda segredo sobre
tudo o que descobriu no processo. Seja um algoritmo novo, seja uma
forma de otimizar código, seja uma modificação feita no sistema
operacional para que o programa se inicie mais rápido, ou uma que faça
seus concorrentes rodarem mais devagar. Essas coisas são as jóias da
coroa de uma empresa de software tradicional. São guardadas a sete
chaves.

Quando uma segunda empresa quiser escrever, digamos, um editor de
textos, vai ter que redescobrir algoritmos de hifenação, formatação,
projetar estruturas de dados que comportem as informações necessárias
e vai, com toda possibilidade, repetir vários erros pelos quais a
primeira empresa já passou. Eventualmente chegará em uma forma
totalmente diferente e secreta de armazenar os textos no disco. E
talvez tenha que inventar um jeito de ler os textos que o primeiro
programa salvou. Terão que investir tempo em conviver com o inimigo.

O mesmo para a terceira, a quarta e todas as outras. Nenhuma avisará
as que a seguem de onde estão os buracos. Algumas nem sairão deles.

O desenvolvimento de software livre é eficiente exatamente por isso.
Ele não precisa ser mais eficiente do que os processos internos das
empresas de software proprietário, porque o mercado que elas geram,
como um todo, é grotescamente ineficiente, um festival de rodas
re-inventadas. Eu não repito seus erros. Os outros não precisam
repetir os meus. Eu não preciso reinventar a roda - posso escolher uma
de várias. Posso precisar pegar essa roda e acrescentar algo a ela. E
todos nós teremos um novo tipo de roda. Se eu faço algo estúpido, você
vem e me corrige. Eu aprendo. E depois posso ensinar alguém. Todos
ganhamos.

Software livre é imune a outros vícios também.

Não há pressão por datas: eu não preciso liberar uma versão do meu
capturador de tiras do Dilbert todo ano. A versão atual tem um ano
desde sua última modificação e ainda funciona perfeitamente. Enquanto
eu não precisar que ela faça nada de diferente, ela fica como está.
Não vamos desperdiçar recursos com isso.

Há uma enorme pressão para se fazer as coisas direito: Como todo o
código é aberto, se você escrever código porco, alguém vai chamá-lo de
porco. Em público. Decisões estruturais costumam ser debatidas e
validadas pela comunidade de desenvolvedores e usuários. Em último
caso, se alguém acreditar mesmo que aquele não é o caminho certo, pode
"fazer um fork", isto é, pegar o código e tudo o que foi desenvolvido
até aquele ponto e começar um novo projeto que seguirá, a partir dali,
caminhos independentes do primeiro.

Não há a pressão por recursos desnecessários: Todos os sinos e apitos
estão lá porque alguém precisava deles (ou, no mínimo, queria muito e
conseguiu convencer bastante gente). Não porque alguém achava que eles
iriam ajudar a vender este produto ou, muito pior, fazer com que você
precisasse de outro produto.

Mas afinal quem paga?. A resposta é simples e, para muitos, chocante:
Software livre não é de graça.

Vou repetir: Software livre não é de graça.

Eu pago (em meu tempo, quando faço eu mesmo, em dinheiro, quando
alguém faz por mim), quando corrijo um erro na documentação, quando
extendo alguma funcionalidade ou quando porto alguma coisa para uma
plataforma nova.

Pago em divulgação, quando peço para um aluno usar o Eclipse em vez do
Borland J-Builder que ele comprou no camelô da porta da faculdade, ou
ainda quando escrevo este artigo. Você paga do mesmo jeito. Ou paga
escrevendo um manual, ou preenchendo um bug-report, ou arrumando uma
página para que usuários do Konqueror ou Mozilla consigam vê-la.
Montes de graduandos de Ciência da Computação pagam, expandindo e
criando software livre.

Meus clientes pagam quando me contratam para construir alguma coisa
usando software livre. No final das contas, continuamos pagando pelo
software.

Isso é importante: Quando você paga, você paga pelo software. Você
vira dono dele. Em vez de pagar caro (ou não) apenas pelo direito de
usar uma cópia de uma coisa que continua pertencendo a outra pessoa. E
ai de você se esquecer que aquilo nunca foi seu. Pela primeira vez na
história, o software é seu, de verdade. Você pode levar pra casa tudo,
mas tudo mesmo, o que comprou. [Webinsider]




Ricardo Bánffy é engenheiro, desenvolvedor, consultor, desarma bombas,
carrega pianos, apaga incêndios, escreve muito mais do que trabalha e
ainda acredita na web.