Fogel (2017, p. 1) afirma que “o software livre – software de código aberto – tornou-se a espinha dorsal da moderna tecnologia da informação. Ele é executado em seu telefone, em seu laptop e computadores de mesa, e em microcontroladores embutidos. Para eletrodomésticos, automóveis, máquinas industriais e inúmeros outros dispositivos que nós frequentemente esquecemos que têm software”.

Esse fato explica o motivo pelo qual, segundo Oram (2015, p. 7), “numerosas empresas estão mimetizando as práticas do poderoso movimento de código aberto para criar uma colaboração corporativa interna sob a rubrica InnerSource”.

O código-fonte é a receita por trás do bolo chamado software. O bolo parece ser mais importante que a receita quando você está com fome, mas após comê-lo, ele deixa de existir. A receita, entretanto, permanece, e a partir dela, infinitos bolos podem ser criados. Se você quiser modificar o bolo, terá que modificar a receita. A receita é o meio de produção, enquanto o bolo é o produto. Assim também o código-fonte é o meio de produção do produto software.

O processo de produção do software de código aberto incentiva a colaboração e permite que o usuário do produto possa participar de sua construção. Essa participação será maior ou menor de acordo com o conhecimento do usuário sobre programação de computadores, mas nunca será inexistente. O usuário sempre terá pelo menos a possibilidade de baixar o código-fonte em desenvolvimento e testá-lo, e com certeza a possibilidade de expor imediatamente a sua opinião, sugerindo e criticando o produto antes de sua versão final.

InnerSource é a apropriação de aspectos do processo de desenvolvimento de projetos de código aberto que mostraram resultado ao longo de vários anos. Um deles é a colaboração ampla entre diferentes times, empresas e nações. Esse aspecto não é algo de fácil assimilação, pois mesmo a colaboração entre times de uma mesma organização exige uma mudança cultural, uma vez que a competição é vista como um processo natural de motivação e alcance de qualidade no desenvolvimento de produtos. Não é fácil convencer as pessoas a colaborarem, mas é possível mostrar a elas que isso dá resultado, lembrando que vários softwares de qualidade que elas usam foram construídos de forma colaborativa.

Entretanto, a colaboração dentro de uma organização, quando assimilada, restringe-se muitas vezes a equipes técnicas. E o usuário, o cliente, aquele para o qual o software é feito, que segundo Mahatma Gandhi, “é o mais importante visitante das nossas instalações”, não é envolvido em todo o processo. Ora, em um projeto de software aberto, o acompanhamento e a interferência são possíveis a qualquer momento. A possibilidade de alterar os ingredientes da receita para ter o bolo desejado está aberta.

Quando se fala em assimilar o sucesso de projetos de código-aberto, foca-se muito na adoção de práticas ligadas diretamente às equipes técnicas, como desenvolvimento orientado a testes, integração contínua e documentação, mas esquece-se de que há um público não-técnico que também participa das comunidades de software aberto e direciona o produto de acordo com suas necessidades, além de contribuir com partes que constituem a fraqueza das equipes técnicas, como a documentação para o usuário final.

O InnerSource na verdade é o primeiro passo em uma evolução no relacionamento entre o produtor e consumidor de software. Ele traz para dentro da empresa (como sugere o nome) as práticas do software de código aberto, mas o desenvolvimento desse software permanece fechado. É como se você estudasse várias receitas de bolo, publicadas livremente, mas na hora de fazer o seu bolo, você não conversasse com ninguém sobre suas ideias para uma nova receita.

Essa questão pode ser justificada com o argumento da segurança: é preciso proteger o segredo da receita. Aqui há um equívoco sobre o que deve ser protegido. Não basta divulgar a receita do bolo, se a receita para um dos ingredientes não estiver disponível. Neste caso, será possível coletar contribuições para o preparo do bolo sem temer que algum outro o faça, se este for o caso.

No caso do software, isso se resolve com arquitetura. A parte sensível, a parte a ser protegida, deve estar desacoplada do restante, cujo conhecimento isolado não trará nenhuma vantagem a terceiros. Entretanto, a parte que não contém o segredo, ao ser exposta, permitirá a contribuição de terceiros, além daqueles para a qual o todo foi destinada.

Ou seja, deve-se adotar o InnerSource como ponto de partida para o OuterSource – a combinação das práticas de projetos de código aberto incluindo a exposição do código para contribuição. E com a possibilidade efetiva de acompanhamento e colaboração por parte dos que requisitaram o software e que vão utilizá-lo.

Referências

FOGEL, Karl. Producing Open Source Software: How to Run a Successful Free Software Project. Disponível em <http://producingoss.com>. Acesso em 17/4/2017.
ORAM, Andy. Getting Started with InnerSource: Keys to collaboration and productivity inside your company. USA. O’Reilly Media Inc, 2015.
ORAM, Andy. Open Source in Brazil: Growing Despire Barriers. USA. O’Reilly Media Inc, 2016.
STOL, Klaas-Jan. FITZGERALD, Brian. InnerSource – Adopting Open Source Development Practices in Organizations. Disponível em <https://www.infoq.com/articles/inner-source-open-source-development-practices>. Acesso em 13/4/2017.

Flávio LisboaBacharel em Ciência da Computação, especialista em Aplicações Corporativas usando Orientação a Objetos e Tecnologia Java, Zend Certified PHP Engineer, Zend Framework Certified Engineer, Zend Framework 2 Certified Architect. Mestrando em Tecnologia e Sociedade, autor pela Novatec Editora, professor de testes unitários na Unicesumar e dono do blog romocavaleirodoespaco.blogspot.com. No Serpro é analista de desenvolvimento da Superintendência de Suporte e Dados.