Confesso que antes de trabalhar em um não conhecia sequer a existência do termo Open Source Program Office (OSPO). Talvez alguém já tenha até me falado sobre isso, mas foi algo que não ficou na minha cabeça e que eu ainda não tinha visto nos ambientes corporativos por onde passei. Acredito que, até hoje, não é costume das empresas nacionais montar um escritório para isso. Quando fui chamado para compor um pesquisei bastante e descobri que, fora do Brasil, é muito mais do que comum para as organizações. Na verdade podemos dizer que é até necessário. As razões? Aparentemente estávamos certos: o modelo Open Source acelera o desenvolvimento tecnológico e facilita a inovação, garantindo que empresas de todo o tamanho se mantenham competitivas em nível global. Mas como isso aconteceu?
Histórico do Open Source no Brasil
Se chegou até aqui já deve ter percebido que Software Livre é um tema que permeia quase toda a minha carreira. Recentemente constatei que trabalho com o tema há mais de 15 anos, e vai ser fácil encontrar bastante material relacionado por aqui. Foi um período em que lutamos bastante para fazer o país acreditar que trabalhar num modelo aberto era melhor para todos os envolvidos (governo, empresas e desenvolvedores), pois enxergava principalmente um ciclo virtuoso na cadeia de valor que facilitaria, em última análise, o desenvolvimento econômico do país. Para que isso fosse possível, era necessário criar um ecossistema de empresas que percebesse a importância do processo e trabalhasse no desenvolvimento de tecnologias de base. Quem não lembra do tempo da Conectiva? Do lado do governo, era preciso fomentar o desenvolvimento tecnológico, transferindo parte (atenção ao termo parte) dos recursos investidos em software para essas empresas. Obviamente percebemos que isso não aconteceu.
E por que isso não aconteceu? Poderia gastar um tempo aqui explicando razões políticas e sociais pelas quais o desenvolvimento tecnológico não é prioridade desse governo e também não foi dos anteriores. Ou ainda explicar porque as empresas nacionais não têm interesse em desenvolver tecnologia. Mas não quero discutir os porquês, e sim apresentar o fato: o tal investimento não aconteceu. Quase todo o aparato tecnológico que permeia o nosso ecossistema de tecnologia, mesmo no contexto de Open Source, é mantido por empresas estrangeiras, com raríssimas exceções. Por não haver investimento interno não foi possível fomentar o ecossistema e os bons desenvolvedores Open Source do Brasil acabaram sendo empurradas em uma das duas direções:
- Foram trabalhar em empresas estrangeiras para continuar desenvolvendo Open Source;
- Foram contratados por empresas nacionais como desenvolvedores e acabaram largando os projetos Open Source.
Eu sei que existem exceções, e vou citar como exemplo a Portabilis do amigo Thiago correndo o risco de ser injusto, mas não obtivemos a relevância tecnológica que imaginávamos sermos capazes. Discutimos o tema mais longamente no artigo publicado pelo Jomar, que apesar de não possuir mais o original disponível online, tem uma cópia integral no softwarelivre.org. O fato é que o viés do desenvolvimento tecnológico ficou para trás, e o Open Source como movimento se manteve em nível global, como discutiremos a seguir, mas o papel de protagonismo que poderia ter sido atingido pelo Brasil acabou ficando no meio do caminho.
Movimento Open Source no mundo
Enquanto vivíamos um cenário no mínimo instável no Brasil, observamos que no mundo o movimento Open Source tomou um rumo bastante diferente. O ponto inicial talvez seja a fundação da Open Source Initiative – OSI, que acabou ganhando tração entre as empresas com um modelo mais robusto de colaboração para o desenvolvimento de software com licenças livres. Não quero entrar novamente no tema que já abordei por aqui muitas vezes, mas sempre se soube que havia uma diferença filosófica entre a OSI e a Free Software Foundation – FSF. Se quiser dê uma olhada no texto que já abordei aqui mais profundamente no tema, mas vou deixar apenas uma das citações que estão por lá:
Os defensores do termo código aberto afirmam que o termo fez com que os empresários percebessem que o software livre também pode ser comercializado. Teriam sido mudanças “pragmáticas” e não “ideológicas”.
Veja que àquela época já se percebia os desafios relacionados à manutenção de um ecossistema de software saudável. Por causa dessa visão, a indústria de software baseada em Open Source já possuía um caráter pragmático percebendo que era sim possível manter um modelo negócios lucrativo. Contudo, não foi apenas isso que fez com que o movimento se tornasse tão importante, e sim o caráter da inovação proporcionado pelo desenvolvimento colaborativo. Para explicar o fenômeno e seu impacto no desenvolvimento de negócios, não apenas de tecnologia, tratemos dois casos: da empresa Goldcorp em meados dos anos 2000 e o recente desafio Netflix.
Open Source e desenvolvimento tecnológico
O primeiro está apresentado no livro Wikinomics [1], que mostra o caso da mineradora Goldcorp, que estava à beira de falência no final da década de 90 por não conseguir encontrar novas reservas de ouro nos terrenos que possuía. A solução inicial foi investir em P&D, que revelou sim possuir mais ouro nos terrenos que já tinha, mas não foi capaz de revelar a localização exata para iniciar a mineração. Como não tinha mais recursos e a empresa ia falir se não conseguisse encontrar as reservas em pouco tempo, o dono da empresa decidiu buscar conhecimento fora do seu Mercado e foi assistir uma palestra de Linus Torvalds sobre o modelo de colaboração no desenvolvimento do Kernel do Linux. Após a palestra decidiu tomar uma decisão no mínimo ousada: abrir todos os dados geológicos de sua empresa para a comunidade de pesquisadores mundial. Não só isso, como ofereceu US$ 575 mil em prêmio para quem conseguisse ajudar a encontrar as reservas de ouro. O resultado foi a descoberta de 110 alvos para extração, dos quais 70% não tinham sido identificados pela empresa, e o aumento do faturamento de US$ 100 milhões para US$ 9 bilhões em aproximadamente 10 anos.
O segundo é bastante conhecido da comunidade de Machine Learning e trata do Prêmio Netflix (Netflix Prize) que distribuía o prêmio de US$ 1 milhão para quem conseguisse melhorar a performance do algoritmo de recomendação desenvolvido pela empresa. Para que isso fosse possível a empresa não só liberou o código desenvolvido por eles como também a base de dados relativos ao consumo de mídias pelos clientes, de forma que a comunidade fosse capaz de produzir seus próprios modelos. O resultado foi uma melhora substancial no modelo de recomendação e a meta estabelecida pela empresa foi atingida dois anos antes do previsto (ia até 2011 e finalizou em 2009). O exemplo foi tão positivo que motivou não só a liberação de outros códigos e modelos dentro da empresa mas também a implementação de uma cultura baseada em colaboração que faz com que a empresa seja reconhecida hoje pela sua capacidade de inovação.
Existem muitos outros exemplos de empresas de tecnologia, como Google e seu Summer of Code (do qual já participei), a cultura de hackatons, e até mesmo a implementação de uma cultura Open Source desde o início nas startups que se tornaram unicórnios nos últimos 5-10 anos. Os exemplos nos ensinam que adotar não somente as práticas de abertura de código mas também a cultura baseada em colaboração aceleram o desenvolvimento tecnológico das empresas. E aí entra a história dos OSPOs: como fomentar essa cultura nas empresas que já são estabelecidas no Mercado?
A consolidação do OSPO
Primeiro é importante ressaltar que a ideia de um Open Source Program Office não é nova nem foi consolidada recentemente. Talvez o primeiro exemplo conhecido pela indústria a explicar o tema e a importância tenha sido o OSPO da Red Hat, que também se preocupou em compartilhar desde sempre a importância de seu papel para dentro e fora da organização. Consigo imaginar que sua origem tenha partido dos antigos community managers ou community relations, aproveitando para mandar um salve para o amigo Rodrigo Padula que conheci à época que liderava o projeto Fedora. Talvez a maior preocupação no momento fosse coordenar os esforços com a comunidade para o desenvolvimento dos produtos Open Source. Mas como não conheço muito o tema deixo aberto para quem tiver mais informações.
Uma mudança importante de mentalidade no contexto dos OSPO chega com o modelo proposto pelo Google, que expande um pouco o contexto de atuação do Office ao trazer a inovação para o centro do jogo. Apesar de não ter falado até o momento, desde o início de sua jornada a empresa sempre foi conhecida por suportar várias comunidades Open Source, além de manter em seu corpo de funcionários um grupo de mantenedores de alguns dos principais projetos. Isso fez com que a cultura de colaboração fosse estabelecida de maneira orgânica dentro da empresa, mas não só isso: acelerou a percepção de que havia algo mais nesse modelo que habilitava a capacidade da empresa para inovar.
Desafios do desenvolvimento Open source
Contudo, apesar de parecer à primeira vista um modelo de trabalho utópico, trabalhar colaborativamente traz desde o começo alguns desafios que não são triviais nem comuns para os programadores e usuários, e lidar com eles é um dos principais papéis do OSPO. O primeiro é o risco relacionado a patentes e propriedades intelectuais, enquanto o segundo está nos desafios de manter a sustentabilidade do ecossistema baseado em colaboração. Comecemos pelo final: os benefícios econômicos já foram discutidos em outra parte do texto. Para as empresas que desenvolvem tecnologia o modelo de negócios se consolidou em duas grandes vertentes: cobrança de subscrição ou serviços agregados. Para a subscrição existem diferentes modelos, mas em geral existe alguma empresa que garante a integridade de uma solução Open Source e se responsabiliza por mantê-la atualizada e segura. Como exemplo do Mercado temos o modelo da Red Hat. Para serviços agregados desenvolve-se uma solução Open Source e a empresa oferece algum serviço que depende dela, como a hospedagem de uma solução do tipo SaaS ou PaaS. Como exemplo podemos citar o WordPress (responsável por este Blog) e todo o seu ecossistema de produtos, serviços e treinamentos.
Já em relação aos modelos e patentes, existe uma crença quase ingênua da maior parte dos desenvolvedores de que isso acontece de forma natural. Se ele baixa sem pagar, normalmente entende que pode usar sem restrições. O problema sempre foi conhecido da indústria, mas ganhou escala global no caso Oracle x Google. No Brasil, o caso mais proeminente foi a disputa de patentes envolvendo a TV Digital (famoso Ginga). Em ambos os exemplos, a mesma questão: utilização de código de terceiros com licença, a princípio, Open Source, mas contaminada por uma disputa de patentes na indústria que durou por muitos anos. Casos como esses mostram os riscos a que estão expostas as empresas, e gerenciar o risco de exposição a patentes e licenças acabou se tornando uma das grandes atribuições de um OSPO. A recente ordem executiva do governo americano reforçou a importância, e deixo aqui um tweet que exemplifica isso.
Thanks, Biden administration! Every company is now going to need an OSPO. https://t.co/IivBRrNXS5
— VanL (@VanL) May 13, 2021
O que faz um OSPO?
Agora que temos um histórico e o contexto, afinal o que faz um OSPO? A definição que está no github do todogroup é a que eu mais gosto, pois se organiza em três palavras: Fear, Love and Money. Parece nome de série do Netflix (como o Gustavo Abrell lembrou), mas se resume a três principais questões: mitigação de riscos legais, trazer as melhores práticas de desenvolvimento da comunidade para o grupo de engenheiros da empresa e, para algumas empresas, habilitar o modelo de negócios. Em relação a mitigação de riscos legais, estamos falando especificamente de licenças e patentes de software, enquanto melhores práticas de desenvolvimento é ensinar os programadores a trabalhar colaborativamente. Sobre habilitar modelos de negócios, envolvem-se as questões financeiras que discutimos anteriormente no contexto da consolidação.
Algumas empresas têm anunciado uma mudança em seu posicionamento para o Mercado, alterando o foco do seu negócio para tecnologia. Na Globo, organização que trabalhava, estávamos numa jornada rumo à conversão em uma empresa Media Tech. O Itaú, empresa que trabalho atualmente, vem numa jornada de transformação digital a partir da compra da Zup para também se reposicionar como uma empresa de tecnologia. Existem diversos outros exemplos dentro e fora do Brasil, mas o que une todas essas empresas é a percepção de que tecnologia passa a ser o centro dos negócios, e não somente um custo. Já escrevi no blog sobre o perigo enfrentado por empresas com presença fortemente digital que tratam tecnologia como custo, e por essa percepção surge a necessidade de se reinventar.
Bom, e o que Open Source tem a ver com isso? Num ambiente competitivo impulsionado por tecnologias as empresas precisam ser capazes de inovar, e isso não significa necessariamente investir mais dinheiro em P&D. Vimos nos exemplos anteriores que o investimento em colaboração é capaz de acelerar a inovação, é já existe um consenso no Mercado de que para isso é preciso implantar a cultura Open Source nas empresas. Criar experimentos pequenos, rápidos e direcionados, testar tecnologias, compartilhar experiências e, principalmente, aprender com os erros, é a principal virtude das empresas que são consideradas inovadoras. Implementar essa cultura é a principal missão de um Open Source Program Office.
Com os exemplos apresentados podemos ver que implementar um OSPO vai muito além de ser um mero ponto de contato com a comunidade: para as empresas de tecnologia, é uma questão de sobrevivência. Todas as empresas, se ainda não têm, deveriam ter um, ou correm o risco de ficar para trás e perderem o ritmo de transformação habilitado através da cultura colaborativa. Além de estarem expostos a riscos que podem posteriormente inviabilizar o negócio.
Obs.: Como não poderia deixar de ser, os OSPO ao redor do mundo também possuem uma comunidade. Visite nossa página para conhecer mais sobre o assunto.
Referências
[1] WILLIAMS, Anthony D.; TAPSCOTT, Don. Wikinomics. Atlantic Books Ltd, 2011.
Posts relacionados:
Author Description
There are 2 comments. Add yours