Introdução

Já faz bastante tempo que software open source existe. Talvez um dos maiores responsáveis por isso tenha sido o sistema operacional Linux que contribuiu para a popularização do modelo.

Apesar disso, ainda vemos muitas empresas e pessoas com certos medos em adotar soluções baseadas em código aberto. Minha idéia com esse post é compartilhar algumas experiências reais que tive com open source no decorrer da carreira.

Para conhecer um pouco mais sobre a história do Open Source, vale a pena ler sobre o Richard Stallman, um dos primeiros “ativistas” sobre o assunto. Aviso antecipadamente: ele é polêmico.

Licenças open-source

Talvez a maior dificuldade em adotar open source esteja relacionada com a licença. Como disponibilizar o código fonte de uma aplicação sem perder os direitos sobre ela?

Para solucionar essa idéia, vieram licenças de código livre, como a GPL – General Public Licence, uma das primeiras e mais polêmicas sobre o assunto. A GPL tem uma idéia que qualquer um pode usar e ter acesso ao código fonte de um software licenciado pela GPL, porém, se modificar o código fonte ou fazer aplicações que se utilizem de qualquer binário licenciado sob a GPL, devem também ser licenciados pela GPL (ou seja, também precisam abrir seu código).

Na prática isso significa que se eu fizer uma aplicação que dependa de uma DLL GPL, minha aplicação também precisa ser licenciada pela GPL. Por essa razão, houve muita crítica a esse caráter viral ou “comunista” da licença GPL.

Por esta razão surgiram licenças menos restritivas como a LGPL, MIT, Apache e outras, que permitem modificações ao código fonte e utilização de binários sem necessidade de royalties.

Quando utiliza-se uma aplicação open-source, como um editor de texto ou um software de controle de versão não há essa preocupação tão restritiva com licenças, visto que pode-se usar gratuitamente o software, mas ao desenvolver uma aplicação é muito importante essa preocupação com qual é a licença do componente que se está utilizando.

O oposto ao licenciamento open-source é o que vemos na maioria das empresas comerciais. No modelo comercial, em geral você não “compra” o produto. Você compra o direito de usá-lo em um computador, por uma pessoa, ou um grupo de pessoas, dependendo do tipo de licença comercial que usa. Se tem algum problema, você entra em contato com o suporte e pede para eles resolverem. No caso do open-source, se você é um desenvolvedor, tem a chance de encontrar e resolver os problemas por conta própria.

Como ganham dinheiro com Open Source?

Apesar de muitos desenvolvedores contribuirem gratuitamente com projetos open-source, por questões de aprendizado ou mesmo alavancagem de carreira, a maioria das empresas que lidam com open-source não vivem de luz. Possuem uma estratégia focada em serviços para conduzirem seus negócios. Alguns exemplos que me vem à cabeça são a CollabNet, que inicialmente começou a desenvolver o Subversion, software de controle de versão gratuíto e open source e vende serviços e outros produtos de cloud, alguns baseados no subversion e outros não e também a SpringSource desenvolvedora do framework Spring, muito popular no mundo Java e um pouco menos no mundo .NET. Além de manter o codigo-fonte vendem serviços de consultoria e suporte comercial.

Outras como a Apache Software Foundation mantenedora do servidor http apache (um dos mais populares e mais usados no mundo), são entidades sem fins lucrativos e recebem doações.

Software open source tem qualidade?

Esse é um dos pontos mais interessantes da discussão. Muita gente questiona como um bando de desenvolvedores malucos que escrevem software no tempo livre podem escrever software melhor do que empresas que remuneram seus desenvolvedores. É um ponto polêmico, mas os fatos podem nos ajudar a chegar a uma conclusão:

• Servidor http: Segundo esta pesquisa, o servidor web Apache (open source) tem mais de 60% de market share, enquanto o próximo da lista não open-source (IIS, da Microsoft), tem pouco menos de 14%.
• Em pesquisas sobre controle de versão, como esta, esta e a pesquisa feita neste blog mostram uma preferência esmagadora por ferramentas open-source em detrimento de ferramentas “pagas”
• Estas estatísticas sobre navegadores de internet, mostram que os de código fechado como Internet Explorer e Safari, tem uma fatia insignificante perto dos open-source

Existem diversas outras ferramentas open-source, desde issue-trackers, editores de texto, ambientes completos de desenvolvimento. Existem tanto ferramentas open sources melhores que pagas quanto o contrário. É o caso da suíte Office, que durante décadas continua sendo a mais usada mesmo existindo alternativas open-source.

Em geral, é muito importante saber quem é a comunidade ou a empresa que está por trás dos projetos open-source, isso é fator determinante na qualidade do produto final (o mesmo critério vale para as pagas!).

Há organização nos projetos open-source?

Depende do projeto, é claro. Este site: Ohloh.net possui muitas estatísticas sobre projetos open-source. É interessante ver projetos com centenas, ou até passando de mil colaboradores e pensar como esse pessoal todo trabalha junto, como garantem a qualidade e o roadmap de melhorias dos produtos.

Muitos destes projetos são hospedados em controles de versão e ferramentas de gestão de projetos hospedados na nuvem como o SourceForge (talvez o mais antigo de todos), o Git Hub ou o BitBucket. A maioria destes hosts utilizam justamente o tamanho e a carga dos projetos open-source que hospedam como argumento para vender serviços de hospedagem para outras empresas e alavancar seus modelos de negócio open-source.

Cada projeto possui uma estratégia de colaboração completamente diferente, mas em geral é muito interessante a organização. Vou citar alguns exemplos práticos de situações que já contribuí.

Projeto Indy

Até me assustei quando encontrei o site do Indy. Pra quem não viveu essa época, eram componentes Delphi para acesso à internet, coisas como http, ftp, e vinham junto com o Delphi, mas eram (ou são?) desenvolvidos por uma comunidade.

Numa dada situação (se me lembro bem, em 2005), precisei de um tipo de request não suportado pelo componente. Fui lá e escrevi a minha classe para resolver o problema e todo feliz e contente fui contribuir com o projeto. Recebi uma negativa polida porque meu código estava totalmente fora do padrão de qualidade deles. Foi frustrante.

SVN::Notify

Em idos de 2006, na minha primeira subida de um servidor Subversion na vida, queria um script para notificação dos commits, bonitinho, igual o cvsnotify que eu já usava a alguns anos. Encontrei o SVN::Notify, feito em Perl e fui todo feliz e contente instalar em Windows. Não funcionava nem com reza brava.

Entrei em contato com o autor e ele me respondeu: Windows? Eu não tenho o menor interesse de fazer o script funcionar em Windows. Se quiser, faça você mesmo.

Foi o que eu fiz. Baixei o fonte, e com toda a minha habilidade de programar em Perl (praticamente nula), corrigi o script. Fiz um “patch”, porque não tinha direito de commit no repositório dele e ele aceitou a modificação. Foi minha primeira contribuição para um projeto open source. Recentemente, instalei um novo servidor SVN e usei novamente o SVN::Notify. Fiquei feliz da vida por saber que ele ainda funcionava em Windows.

Spring.NET

Em 2007, trabalhei num projeto em Spring.NET. Como todo early adopter, tive problema com um bug. Baixei o código-fonte e rapidamente consegui rastrear que era um bug.

Entrei em contato com a lista de discussão dos desenvolvedores e rapidamente o problema foi reconhecido como um bug e registrado no issue tracker. No mesmo dia, recebi um patch com uma correção paliativa do problema e um mês depois a versão oficial foi lançada, incorporando a correção final.

FluentCodeMetrics e MSBuild.Community.Tasks

O FluentCodeMetrics é uma biblioteca .NET para ajudar na extração de métricas de código e o MSBuild.Community.Tasks uma biblioteca de tasks para o MSBuild.

Em ambos os casos foram algumas contribuições bem simples em situações que foi muito mais simples eu contribuir para um projeto já existente do que tentar criar outro e popularizá-lo.

Por serem repositórios hospedados no Git Hub, seguem o fluxo do próprio Git Hub: Você faz uma cópia do repositório para você (Fork), altera o seu repositório, entrega a contribuição no seu repositório no Git Hub (push) e avisa o autor que existe uma contribuição ali e pede pra ele pegar sua contribuição (Pull Request). Se ele quiser, ele incorpora no repositório principal.

Alguns exemplos de pull request: Issue corrigida no FluentCodeMetrics e Nova task GitVersion no MSBuild.Community.Tasks.

Jenkins

Essa é uma contribuição simples e recente, mas que ilustra um pouco do espírito de organização dos times open-source. O Jenkins é um servidor de integração contínua, provavelmente um dos mais populares e mais usados. Por isso provavelmente a melhor organização.

Encontrei um bug num dos seus plugins (build pipeline) que estava me atrapalhando um pouco. Consultando no issue tracker deles, percebi que já existia um bug aberto sobre o assunto.

Eu não sou especialista em Java, mas de nada custava dar uma olhadinha no Bug. Baixei um netbeans, fiz o fork do repositório no git hub, em algo em torno de 2h consegui encontrar o bug e corrigi. Fiz o pull request.

O supreendente é o comentário que veio no pull request: plugins » build-pipeline-plugin #82 SUCCESS. This pull request looks good.

Rapidamente percebi que o meu pull request, disparou um processo de integração contínua, que roda num Jenkins na nuvem. Lá, os testes unitários e de aceitação foram executados e o serviço automaticamente comentou o pull request avisando que ele “parece bom”. Mesmo assim, o pull request não subiu imediatamente para o repositório oficial. Na seqüência um colaborador do time do Jenkins fez o merge.

Como é a organização do seu time?

Conversando com diversos profissionais na área, percebemos que o uso eficiente de uma ferramenta de controle de versão infelizmente é algo ainda raro, integração contínua um desejo e testes unitários e de aceitação um tabu.

É claro que existem times que praticam tudo o que foi visto nesse exemplo do Jenkins assim como existem projetos open-source de uma pessoa só ou abandonados, mas se investigarmos um pouquinho mais, veremos que na maioria dos projetos mais ativos open-source, essas práticas são requisitos básicos para garantir a qualidade do produto final. Isso me faz acreditar, empiricamente, que a organização de times open-source é muito superior que a média, servindo de referência para times grandes, complexos e geograficamente distribuídos.

Mesmo em empresas que diferentes times de desenvolvimento conduzem produtos diferentes e um encontra problemas ou oportunidades de melhoria no código do outro, nunca vi um mecanismo como os pull requests do Git Hub para simplificar o processo de proposta e aceitação da correção ou melhoria.

E o suporte?

Sempre que surge uma discussão sobre adotar ou não open source, esse ponto é colocado na pauta. E o argumento mais utilizado é: Eu prefiro pagar para usar o software porque posso processar alguém se algo der errado.

Já ouvi isso incontáveis vezes. Em todos os exemplos que citei acima, consegui resolver o problema por conta própria. As razões disso são muito simples:

• Projetos open-source são muito utilizados. A quantidade de informações existentes em blogs, sites de perguntas e respostas com o Stack Overflow é impressionante. Ferramentas pagas, de menor utilização possuem menos material de referência
• Projetos open-source possuem listas de discussão ativas. Todas as vezes que tive algum problema e o comuniquei de forma respeitosa e com evidências em listas de desenvolvimento, fui prontamente atendido.
• Ter o código fonte em mãos simplifica a localização e correção de bugs
• Se tudo mais der errado e o grupo de desenvolvedores sumir, você pode dar continuidade na manutenção do código-fonte e outro grupo provavelmente o fará

Além desses pontos, vale lembrar que muitas ferramentas open-source possuem empresas que dão suporte comercial. Existe também muitas gigantes que embarcam software open-source junto com partes de software comercial. É o caso da IBM que utiliza Eclipse (open source) como base para a interface de diversos de seus produtos (toda a suite Rational por exemplo) e o caso da Oracle que a algum tempo atrás embarcava o servidor http Apache como parte de alguns de seus produtos (não sei ao certo se ainda é assim).

Na contramão, tive duas experiências muito interessantes com suportes comerciais de gigantes de software. Obviamente não vou citar o nome das empresas.

Numa situação, estávamos desenvolvendo uma aplicação em cima de uma API e tivemos problemas na utilização desta API. Acionamos o suporte “gold” que tínhamos direito e após umas duas semanas, o problema escalou para o segundo nível, sem solução. Após um mês, para o terceiro nível. Depois de um mês brigando com o bug, acabei encontrando sozinho a causa raiz dele e uma solução de contorno. Resolvi não comunicar o suporte que tinha encontrado a solução, para ver quanto tempo demorariam para me dar um retorno. Após 3 meses acompanhando a situação sem receber qualquer resposta, desisti de acompanhar o problema.

Numa outra situação, encontrei um bug no driver de um produto. Entrei em contato com o suporte e a primeira reação deles foi tentar desqualificar o bug, dizendo que o driver não fazia parte do produto, logo, não dariam suporte. Após convencê-los que o problema estava numa DLL fornecida no pacote de instalação do cliente do produto, se convenceram. A segunda reação foi argumentar que não era um bug. Após enviar uma boa quantidade de traces que não deixavam qualquer dúvida sobre a existência do problema, continuei não recebendo nenhum bug fix, patch ou correção. Após cada pedido de solução uma nova quantidade de traces era pedida. Desisti de acompanhar o problema após 5 meses de discussão e conseguir uma solução de contorno que não resolve totalmente o problema. Apenas faz com que ele ocorra com uma incidência menor.

Em todas essas situações que vivi, nunca vi qualquer intenção de processar qualquer um dos fornecedores pelos prejuízos causados.

Por outro lado, cada vez mais vemos gigantes que sempre tiveram fama de serem “fechadas” como a Microsoft, com iniciativas estratégicas baseadas em open source. Com o objetivo de aproveitar os feedbacks e contribuições da comunidade de desenvolvedores, a Microsoft abriu o código fonte de alguns de seus projetos, como o Signal R e também o projeto Roslyn. O Roslyn é simplesmente a plataforma de compiladores C# e VB.Net (!).

Conclusão

O modelo de software open-source (com e sem fins lucrativos) está presente e em pleno crescimento. Cada vez mais soluções open-source são adotadas em cenários críticos e não críticos.

Algumas empresas estão visualizando o diferencial competitivo que o modelo oferece, tanto empresas consumidoras de TI, com o objetivo de minimizar custos ou obter melhor valor agregado nos serviços quanto empresas fornecedoras de TI, com o objetivo de acelerar o desenvolvimento (usando componentes) como prestar serviços baseado em plataformas open. Outras empresas continuam resistindo ou mesmo ignorando o modelo. Acredito que a maioria delas por pura falta de conhecimento sobre bons cases de sucesso utilizando ferramentas open e desconhecimento do modelo de operação/desenvolvimento.

Pelas experiências que já passei, recomendo sempre considerar a utilização de ferramentas open, levando em consideração as questões levantadas no post como licença, suporte, “quem está por trás” do projeto e quem utiliza o projeto (cases). Em resumo, ter as mesmas preocupações que temos quando vamos fazer qualquer investimento.