- Uma versão adaptada foi publicada como um Minipaper do Technical Leadership Council da IBM Brasil [w3], em 27 de dezembro de 2006.
- Como referência, este é um assunto muito denso e me deram aproximadamente 500 palavras de espaço, então tive que simplificar algumas coisas e/ou não entrar em áreas interessantes como os desobramentos sociais de OSS.
- Mais artigos
O primeiro a propor a idéia de Open Source Software (OSS) foi Richard Stallman na década de 1970, que a formalizou, com a ajuda de alguns advogados, na famosa licença GPL.
Ninguém se interessou ou sequer ouviu falar sobre isso, até que em meados da década de 1990, tudo mudou com a vertiginosa popularização do Linux, sistema operacional OSS.
O termo popular “Software Livre” não é a melhor tradução de Open Source Software, cujo correto é Software de Código Fonte Aberto. É importante notar isso porque muitas vezes o termo é erradamente associado a idéia de não-proprietário, ou não-comercial. A verdade é que um software pode ter seu código fonte aberto mas ser comercial e/ou proprietário e vice-versa, portanto são conceitos que não devem ser confundidos.
A idéia é simples: eu escrevo um programa e você pode copiá-lo à vontade sem nem sequer me notificar. Pode inclusive modificá-lo e redistribuí-lo, contanto que também mantenha suas modificações abertas e informe qual a origem e os autores anteriores do software.
Isso não quer dizer que teremos diversas versões desconexas do mesmo software, num dado momento. Cada modificação passa por um processo muito bem organizado de aceitação ou rejeite, onde boas melhorias retornam à base e são incorporadas à nova versão do software. Na verdade, hoje, a maioria dessas contribuições não é mais feita por indivíduos, mas por empresas de tecnologia.
É comum — e errado — pensar que OSS significa a morte de todo software de código fechado. Isso não acontece porque a tendência é que as grandes inovações continuem a ser exploradas pelo modelo fechado. Imagine um mundo hipotético que ainda não conhece editores de planilhas. É natural que, ao lançar esse produto, seu inventor opte pelo modelo de código fonte fechado, para maximizar seus lucros através do total controle de sua invenção. Contudo, conforme essa invenção se populariza, desenvolve um mercado e adquire concorrentes, OSS surge como uma das formas — a mais inovadora — para repensá-la. OSS inova ao reimplementar o que outros inventaram e exploraram anteriormente. Recentemente, porém, a indústria começou a usar OSS diretamente para lançar certas inovações, justamente pelo seu poder de agregar comunidades e criar ecossistemas.
Também é comum — e errado — acreditar que se o software em si é gratuito, elimina-se por completo os gastos. Mas sempre haverá a necessidade de um suporte confiável. OSS altera o eixo do valor agregado do software, movendo-o do software em si (que não custa nada), para o serviço de suporte.
Em seu processo de amadurecimento, a única diferença prática entre um software OSS e outro de código fonte fechado é a ordem em que as coisas acontecem. Um fabricante comercial terá que criar estrutura e suporte regional antes de vender o produto. Já no OSS, ofertas de suporte só surgem (espontaneamente) depois que ele goza de uma boa gama de usuários. Mas seja qual for a ordem, a única coisa que garante maturidade a qualquer software ou produto é um ciclo de desenvolvimento–uso–suporte, que estimula mais desenvolvimento. Somente essa maturidade garante a aceitação do produto em empresas responsáveis. E hoje, OSSs como Linux, Apache, OpenOffice.org, Samba, e outros já gozam desse ecossistema cíclico de uma forma vasta, global e vigorosa.
Hoje, OSS tem aplicações mais maduras em infraestrutura e alguns nichos de middleware. Por sua vez, os softwares de código fonte fechado apresentam maior desenvoltura mercadológica nas funcionalidades de maior valor agregado ao negócio (ERPs, CRMs ou processos empresariais). Isso porque estas funcionalidades têm uma amplitude menor de usuários, o que inviabiliza o surgimento de suporte espontâneo — fator vital para a maturidade do OSS.
A indústria tem buscado um balanço saudável para misturar componentes fechados com OSS, a fim de maximizar o seu benefício sem abrir mão da maturidade de ponta a ponta. Prova disso é que tem sido cada vez mais comum a implantação de ERPs maduros — geralmente de código fechado — sobre plataformas abertas maduras — como distribuições Linux com suporte.
A receita para o melhor balanço é insistir no uso de Padrões Abertos. Por garantirem uma interoperabilidade fácil entre camadas abertas e de código fechado, o uso de padrões amplia as escolhas e a liberdade da empresa que compra TI para compor a melhor mistura do momento, com opções OSS e/ou de código fechado.