Quem paga a conta do software livre?

Por 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). 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 pra 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 seus concorrentes, entre eles a Sun, levassem seus 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). 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 2 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.

Publicado originalmento no endereço: http://www.linhadecodigo.com.br