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).

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

Ricardo Bánffy (ricardo@dieblinkenlights.com) é engenheiro, desenvolvedor, palestrante e consultor.