Tag: tech:ok

Num evento promovido na Universidade Federal de São Carlos eu fiz uma palestra longa sobre middleware IBM em Linux. No final os estudantes fizeram ótimas perguntas sobre carreira, trabalho, tecnologia e uma das mais interessantes foi essa do título.

A resposta rápida é: se um software fechado ainda traz lucro para seu dono não há porque abrir seu código fonte.

Mas na verdade essa é uma questão deveras delicada, e a decisão é muito difícil de se fazer.

Um software tem dois grandes valores:

1. O valor de seu código, ou o quanto o mercado valoriza financeiramente a quantidade de trabalho empregada para desenvolver aquele software.
2. Seu valor ecossistêmico, ou quantas pessoas conhecem bem esse software e estão prontas para trabalhar com (e para) ele, usando, desenvolvendo extensões, escrevendo livros, etc.

O segundo ponto é mais difícil de entender, então para explicar tomemos como exemplo o Adobe Photoshop versus o Gimp. O último tem a maioria das funcionalidades do primeiro e é de graça, mas o primeiro continua sendo muitíssimo mais popular, conhecido, usado, etc. O valor ecossistêmico do Photoshop é bem maior que o do Gimp e isso inclusive aumenta seu valor financeiro.

E para o primeiro ponto, lembrem-se do excelente webserver de código fechado da Netscape que perdeu a guerra ao se deparar com o Apache HTTP Server. O mercado não estava mais disposto a gastar dinheiro com algo tão simples e estrutural como o código fonte de um webserver.

Se você abrir o código cedo demais, vai perder lucro, mas se esperar muito pode perder ecossistema porque seus usuários irão migrar para opções abertas mais flexíveis e mais baratas. A qualidade geral da opção aberta talvez seja inferior num certo momento, mas conforme seu ecossistema cresce, a qualidade também cresce talvez ultrapassando as alternativas fechadas.

Há duas vantagens em abrir o código fonte:

1. A primeira é tática e está relacionada a terceirizar o trabalho massante de manter um código que não tem mais valor comercial, mas que ainda é vital para outros produtos de maior valor.
2. A segunda é de ordem estratégica e muito interessante. Consiste em usar o poder social do Open Source em agregar comunidades e assim estabelecer um padrão na área do código que foi aberto. Isso aniquila a concorrência, e se não há um padrão geral estabelecido, a abertura bem sucedida e amadurecida define um Padrão Aberto.

Abrir só com o primeiro ponto em mente, geralmente leva ao fracasso. Foi o caso do Darwin e o OpenSolaris, pois não conseguiram criar ao seu redor um ecossistema viável para sobreviverem sem seu criador. Seu código foi aberto muito tarde, tão tarde que Linux já dominava a cena de sistemas operacionais.

Quando há um equilíbrio entre as duas vantagens acima, abrir o código fonte pode mudar completamente o rumo do mercado naquele setor. Foi o que aconteceu com o Eclipse e o OpenOffice.org. No caso do Eclipse, era uma grossa camada de código muito bem feito mas que dava muito trabalho para manter. Além do fato de que o verdadeiro valor de produto estava no que ficava sobre o Eclipse, como o antigo WSAD da IBM. Quando foram abertos, não havia nem sombra de algo similar em código aberto e com aquela qualidade. O resultado hoje é uma comunidade dinâmica ao seu redor que está levando esses projetos onde nunca se imaginava poderem chegar.

O poder de uma abertura estrategicamente bem pensada pode abalar as bases de um produto bem estabelecido. É o caso do OpenOffice.org mais ODF versus o MS Office e todo o barulho que temos ouvido na mídia e nos governos.

Hoje, softwares que implementam conhecimento muito específico de áreas avançadas como engenharia, arquitetura, negócios, logística, etc estão longe de serem abertos, simplesmente porque o mercado ainda remunera bem seus fabricantes. Há opções abertas, mas é tão difícil criar e autosustentá-las de forma global e com qualidade, que as opções fechadas ainda são melhores.

E softwares que implementam funcionalidades de uso genérico como o de um sistema operacional, servidor de arquivos, webserver, etc, graças ao mundo pequeno que a Internet nos ofereceu já dominam seu escopo inclusive em termos de ecossistema, e ninguém mais se arriscará a criar um concorrente de código fechado. A excessão aqui é o Microsoft Windows, único sistema operacional proprietário e de código fechado, que ainda detém um ecossistema gigante.

Já estamos vivendo uma época em que a decisão de abrir o código fonte não está mais no âmbito da infraestrutura. Nos próximos anos provavelmente vamos ver middlewares populares terem seus códigos abertos. Open Source está avançando nesse setor, e a capacidade dos gestores dessas áreas em tomar decisões inovadoras será o que vai diferencia-los da concorrência.

Isso acontecerá num ritmo natural. Não se pode mudar os nove meses de uma gestação. São idéias que naturalmente estão amadurecendo no mercado.

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.