Esse primeiro artigo vem de encontro a uma série de perguntas que recebemos ao longo das visitas e contatos comerciais. Acreditamos que explicar o caminho para as decisões que foram tomadas até agora também é importante, por isso o artigo trata deste assunto. As perguntas mais relevantes estão relacionadas aos motivos pelos quais a Infranology adotou determinadas tecnologias open source utilizadas no nosso dia a dia.

O Início

No início da vida da empresa desenvolvíamos soluções com um software proprietário e desde 2006 a empresa vem sendo direcionada para projetos que utilizam uma base de código open source. Ao longo da adoção das soluções em open source, alguns problemas surgiram, como por exemplo:

• Manutenção de código: em nossos projetos, uma vez que o código raiz era alterado, nem sempre conseguíamos nos manter alinhados com o tronco principal de código. Parte dos problemas eram nossos, mas a grande maioria era causada por decisões na raiz do projeto.

• Segurança: revisar 100% do código de um projeto open source, mesmo que necessário, torna-se uma tarefa impraticável.

• Testes automatizados: até hoje os projetos open source são problemáticos em relação a este tópico. A adoção efetiva de frameworks de teste é recente e vem crescendo, mas no início a realidade era bem diferente.

• Versionamento: mantemos repositórios internos quando possível e versionamos o que é possível. Muitas vezes o próprio projeto de open source não considerava esse tipo de trabalho para quem adota este tipo de procedimento. A maior mudança ocorreu com a adoção de sistema de versionamento distribuídos como o git.

Estes são alguns dos pontos levantados ao longo do tempo que utilizamos os mais diversos projetos, desconsiderando incidentes normais do caminho como forks, migração de open para closed source e encerramentos de projetos.

Novos rumos

Depois de conviver com a realidade descrita anteriormente ficou claro, diante das dificuldades impostas pelo processo adotado, que deveríamos nos concentrar em um número menor de soluções e definir critérios mais claros para trabalhar com open source, oferecendo um serviço mais especializado, confiável e que suporta nossos clientes de forma mais adequada.

De usuário a contribuidor

Um outro ponto que parecia natural durante a evolução dos nosso conhecimento é o fato de passar de uma empresa que “se utiliza de soluções open source” para uma empresa que “contribui com projetos open source“.

Este é um tema controverso e mesmo grandes projetos trabalham em cima de um formato para atingir um ponto de equilíbrio entre o open source e os resultados financeiros gerados por esse trabalho.(1).

No Brasil estamos acostumados a contribuir com traduções para português e este é um outro ponto criticado por quem acompanha projetos dessa natureza. Nesse caso nossas empresas apenas tornam-se boas usuárias de uma plataforma e contribuem com tradução e muita conversa. Portanto precisávamos trabalhar para fazer parte dos projetos open source que oferecemos aos nossos clientes.

Maturidade

Portanto entendemos a necessidade de reduzir o volume dos projetos open source que utilizávamos e com isso iniciamos uma tentativa de contribuir com eles da melhor maneira possível. Com a palavra contribuir queremos dizer fornecer internos recursos (recursos humanos e financeiros) para projetos e grupos de desenvolvimento externos a nossa empresa.

Nossa experiencia anterior nos fez buscar projetos de open source que apresentavam um estágio de maturidade mas avançado (2). Assim poderíamos contribuir e aprender (sempre que possível!!) com o decorrer do projeto.

Os Projetos

Observando o nosso portfólio de trabalhos notamos que dois tipos de solução apresentavam um certo destaque: projetos de código customizado e soluções de CMS (Content Management System). Assim ficou claro que precisávamos definir soluções que tratassem dos dois tipos de problemas.

Para tratar das soluções de CMS atualmente utilizamos o Drupal e para tratar das soluções especializadas utilizamos o Symfony como plataforma.