[VIDEO] O que é open source, para que serve e como pode ajudar na sua carreira como dev?

O que é open source? É software de graça? É só baixar e usar? Essas são dúvidas que sempre podem causar uma certa confusão. E causava mais ainda quando havia um termo, que surgiu antes do open source, intitulado “free software”. Mas existe ainda um termo que é a combinação desses dois conceitos: “FLOSS: Free/Libre and Open Source Software”. Você também pode ter a impressão de que, em algum momento da história da computação, o termo “software” foi criado, e aí alguém simplesmente resolveu abrir o código-fonte do programa. Mas, não é bem assim. Na verdade, é o contrário.

Open source: uma breve introdução

No começo, os programadores, que eram bem poucos, não ligavam muito em compartilhar seus códigos-fonte, até porque essa era a regra vigente na época, como também era - e ainda é! -  da cultura da academia compartilhar conhecimento. A computação nasceu em um campo restrito, e vale lembrar que a maioria dos programadores eram também pesquisadores. E ninguém ligava muito para o software, porque era bastante simples e muito barato. O que custava muito dinheiro, na verdade, eram as máquinas (hardware).

Para se ter uma ideia, um computador custava tão caro que somente empresas muito grandes ou órgãos governamentais podiam adquirir essas máquinas. Ninguém ligava muito para o software, que também era limitado naquela época. Mas, conforme as máquinas foram ficando mais baratas, no alvorecer dos anos de 1970 e início dos 1980, eis que surge então o que passamos a conhecer por “computador pessoal”. Com isso, o software começa a ganhar evidência e a ficar mais poderoso. Em contrapartida, algumas empresas começam também a perceber que poderiam lucrar com a venda desses programas.

Microsoft vs IBM

É curioso como as pessoas em geral não fazem ideia de coisas como, por exemplo, o fato da Microsoft ter sido contratada para desenvolver o sistema operacional do famoso computador pessoal da IBM que, por sua vez, resolveu abrir toda a arquitetura - ou seja, qualquer um poderia copiar a arquitetura do PC e criar clones, e foi de fato o que aconteceu.

A Microsoft era então uma empresa muito nova, e agarrou a oportunidade com unhas e dentes, mas com uma condição: ser livre para vender o sistema operacional para qualquer pessoa. E, naquela época, o comentário da IBM foi o seguinte: “tudo bem, software não dá dinheiro mesmo, o que dá dinheiro é hardware”.

Hoje sabemos que eles (da IBM) estavam redondamente enganados. Na verdade, o software deu MUITO dinheiro, e acabou se tornando um produto. Enquanto ninguém vendia software, não havia problema em compartilhar o código-fonte. Mas a partir do momento em que você vende software como produto, o código-fonte tem de ser fechado, para ninguém poder copiar.

Era um momento em que o software podia ser confundido com a mídia no qual era distribuído e assim o imaterial foi materializado para ser comercializado. Em menos de uma década, o modelo de software proprietário, ou de código-fonte fechado, tornou-se o padrão, como se sempre tivesse sido assim. Fim da história? Não exatamente: algumas pessoas não concordaram em nada com isso, e resolveram agir.

Free Software Foundation

Nos anos 1970, um físico chamado Richard Stallman, que trabalhava no MIT, ficou revoltado quando descobriu que não poderia mais alterar o código do programa que controlava sua impressora. Ele resolveu então criar um movimento para lutar pela abertura e manutenção dos códigos-fonte, e em 1985 nascia uma entidade chamada “Free Software Foundation” - que, por sinal, existe até hoje. Stallman desenvolveu um sistema operacional - na verdade, ele fez cerca de 80% do sistema operacional - e levou quase 10 anos para isso, mas não conseguiu criar o “núcleo” (kernel) do sistema.

Esse feito caiu na conta de um outro rapaz, um jovem originário da Finlândia, chamado Linus Torvalds. Linus desenvolveu o que hoje conhecemos por Linux, e que na verdade é justamente o núcleo do sistema operacional, também chamado de kernel. Mas ele tinha uma vantagem em relação ao Stallman, considerado uma pessoa, digamos, um pouco difícil de lidar - Linus foi quem conseguiu a façanha de reunir muita gente, de lugares e países diferentes, para trabalhar em um projeto imenso e audacioso: o sistema operacional Linux. Hoje contando com inúmeras distribuições mundo afora, o sistema operacional criado por Linus Torvalds tornou-se tão popular que até mesmo o celular que você usa pode estar rodando com uma variação do Linux, caso seja um modelo Android.

Mas, não para por aí: ele está também em muitos servidores pelo mundo, incluindo a Nasa, e os robôs lançados em Marte. Tudo isso é open source, ou seja, são sistemas que possuem o código aberto, e você (mesmo) pode acessar um site (repositório) e copiar, fazer modificações nesse código, e pode até criar um novo produto para vender e ganhar dinheiro com isso! É o que chamamos de open source ou código aberto - software livre e código aberto fazem referência à mesma coisa, basicamente.

Open Source Initiative

No fim dos anos 1990 surgiu uma entidade chamada “Open Source Initiative” (OSI), que finalmente cunhou o termo “open source”, algo bem melhor que o “free software” conhecido até então. Isso porque free software em inglês também é entendido como “software grátis”, já que “free” pode significar “grátis” ou mesmo “livre”, gerando aquela confusão básica com “freeware” - que é software de graça mesmo - mas, atente para o detalhe: apesar do “free” no nome, o código-fonte neste caso não está aberto.

O que a OSI fez foi justamente criar uma iniciativa para enfatizar a parte do código que é aberto para colaboração, e sobretudo que pode ser usado para gerar negócios. E é bem aí que entra a divergência com a Free Software Foundation, uma vez que esta enfatiza a “liberdade” - as pessoas precisam ter a liberdade para saber como o software funciona - o que é diferente entre software livre e software de código aberto, o famoso “open source”. Recapitulando, em resumo o software nasceu livre, passou um momento em que se tornou proprietário, e atualmente convive com esses modelos: código aberto e código fechado. Eles convivem juntos, e tão pacificamente, que existem empresas gerando produtos e serviços ao trabalhar de maneira simultânea com os dois modelos de software.

Open source em números

Um relatório de 2021 da RedHat, entidade que comercializa customizações do Linux para empresas, apontou que cerca de 50% das organizações entrevistadas revelaram usar software open source para modernizar suas infraestruturas de TI. Para elas, o maior benefício é justamente o fato do open source ajudar a melhorar a qualidade de seus softwares, sendo que 38% dariam preferência na seleção de um profissional que houvesse contribuído com plataformas open source. Agora, porque será que essas organizações dariam preferência para pessoas com esse perfil?

Para responder essa e outras tantas perguntas envolvendo o mundo open source, realizamos um debate, moderado por Flávio Lisboa, grande referência da comunidade PHP do Brasil há mais de 10 anos, professor e analista de sistemas no Serpro (considerada maior empresa pública de tecnologia da informação do mundo), tendo como interlocutores Douglas Iacovelli, Mobile Tech Lead na Revelo - que participou da equipe de desenvolvimento da primeira versão do nosso app - e Gabriel Araújo, engenheiro civil de formação que se apaixonou por desenvolvimento de software, fez transição de carreira dentro da Revelo e atualmente trabalha como desenvolvedor Flutter.

Tópico 1: Início da experiência em contribuições open source

Flávio Lisboa: Como vocês começaram a contribuir em projetos open source e como isso ajudou na carreira de vocês?

Douglas Iacovelli: Eu usei código open source durante muitos anos na minha carreira, mas nunca tinha contribuído; demorei muito tempo para dar esse primeiro passo, porque sempre achei que era algo muito complexo. Programei com código aberto praticamente todas as bibliotecas que usava na época em que trabalhava com Android. Quando comecei minha carreira, programava com PHP também, com Cake PHP, que é um framework de código aberto; então, acho que boa parte da minha carreira eu sempre fui um grande usuário de código aberto, mas sempre tive muito receio de ir lá olhar, talvez por falta de mentoria, ou mesmo por falta de confiança.

E aí, mais recentemente, quando comecei a pegar mais experiência e a entender melhor como o código funcionava, consegui ser mais capaz de olhar o código de outra pessoa, principalmente de uma biblioteca de código aberto. Acredito que a maior parte dos códigos vão ficando naturalmente mais complexos, porque pega pessoas do mundo inteiro contribuindo, então, com a experiência eu comecei a entender melhor esse código.

Há uns 6 meses atrás, passei por um problema específico no Flutter, para o qual não conseguia encontrar nenhuma solução dentro do próprio framework - ou seja, ele não tinha uma solução para aquilo que eu buscava. Depois de procurar saber se já existia um código para resolver o meu problema, decidi abrir uma issue e pedir ajuda da comunidade. Foi então que eu recebi um comentário de um dos mantenedores do repositório, dizendo assim: “porque você não contribui pra gente? o que você acha?”. Aí acendeu uma luz na minha cabeça e eu pensei: “quer saber, eu vou tentar”.

Aí eu fiz o código, a primeira versão não ficou boa, ele me deu vários feedbacks, e nesse processo de indas e vindas, umas duas ou três vezes, acabei aprendendo um monte de coisa que eu não tinha aprendido enquanto era só usuário do repositório. Então na hora que eu coloquei a mão no código e recebi o feedback/mentoria de uma pessoa com muito mais experiência que eu, nossa, foi incrível! Aprendi muito com essa experiência e a partir daí comecei a recomendar para todo mundo.

Gabriel Araújo: Recomendou para todo mundo e até eu caí no conto, rs. Eu sou dev junior ainda, tenho experiência no mundo corporativo, mas com desenvolvimento de software eu comecei mesmo faz pouco mais de um ano. Nunca pensei também que iria contribuir para um projeto open source, ou que fosse conseguir fazer isso. Até porque, como o Flávio falou, geralmente a qualidade das pessoas que desenvolvem para projetos open source é uma coisa assim fora do padrão; são pessoas geniais que conseguem fazer as coisas do zero. Sempre tive muito receio de abrir uma lib (biblioteca), entender o que estava escrito ali e como funcionava a documentação.

Até cair no mesmo cenário que o Doug comentou: queria resolver um problema, fui fazer o update de uma lib, e notei que esse update não “conversava” com umas dependências dessa lib. Daí eu pensei: vou ficar com o projeto travado, sem poder fazer o que preciso fazer, se ninguém consertar isso. Aí fui conversar com o Doug e ele me disse: “porque você não abre um pull-request para isso? Você entende como a lib funciona, faz o código, e manda lá.. quem sabe você mesmo não consegue fazer? quem sabe eles não aprovam depois”? E foi exatamente o que aconteceu!

Para mim, essa parte de contribuir com projetos open source é uma coisa que cresce bastante porque, em primeiro lugar, eu perdi o medo de olhar para libs, de buscar entender como as coisas funcionam realmente ali por trás do código “bonitinho”, que mostra como você deve utilizá-lo; e também uma coisa muito legal que me motiva é ver que consigo ajudar a melhorar algo para a comunidade e deixar um pouquinho melhor ainda do que já estava antes. Nunca pensei que fosse fazer teste para uma lib, e acabei fazendo teste também para poder ficar melhor e realmente provar para pessoa que era a dona do repositório que o que eu fiz estava funcionando, que os testes unitários estavam passando, e que faria total sentido fazer o merge. No final, foi uma coisa bem legal que só teve um “looks good to me” (LGTM). E fiz o merge.

E isso é uma coisa que eu acho muito bacana: a gente tem um problema e com o open source tem o poder de agir em cima, de entender a fundo como as coisas estão funcionando, e ajudar realmente a comunidade toda. Parece que um pull request que a gente faz já está ajudando mais pessoas a não passarem pelo mesmo problema, mas a seguir em frente e melhorar o código cada vez mais, para toda a comunidade.

Tópico 2: Contribuição open source não é trabalhar de graça, e sim a devolução de algo que você usou gratuitamente e que outras pessoas construíram antes de você

Flávio Lisboa: Vocês falaram de coisas bastante interessantes, como a questão de poder resolver um problema quando está usando um software e percebe que falta alguma coisa nele. Daí você pensa: poxa, eu posso melhorar isso aqui! Mas, quando você não tem acesso ao código-fonte, não pode modificar esse software; teria que pedir - na verdade, pagar - para o fornecedor fazer a alteração requerida. Mas quando você mesmo pode fazer a alteração e usar imediatamente aquilo que você modificou, é quando percebemos como o software de código aberto é importante, pois oferece justamente essa possibilidade. O código aberto confere todo o poder ao usuário sobre aquilo que ele está utilizando - e é essa mesmo a ideia.

Agora, e essa palavra “contribuição”? Ela pode dar a impressão talvez de “estar trabalhando de graça”. Na verdade, a contribuição que você faz também funciona como uma espécie de devolução, uma vez que você está usando algo gratuitamente que outras pessoas construíram antes de você. No fundo, você está devolvendo um pouco daquilo que utilizou, e de quebra também está melhorando aquele código para outras pessoas, assim como outras pessoas entregaram aquele código-fonte para você poder utilizar.

Além disso, um efeito colateral é que, ao contribuir com o código aberto, você não consegue se esconder, as pessoas sabem que você fez aquilo, seu nome está lá, o seu nickname está associado ao código. E as pessoas sabem que você conseguiu fazer aquilo, e se aquela sua alteração faz parte da versão do software que funciona, uau! “Esse cara fez um negócio que funciona”! E aí pensando em carreira, não é como chegar na entrevista e a pessoa perguntar “você sabe isso?” e ouvir a resposta: “ah, sim, eu sei”; mas a verdade é que o recrutador só vai descobrir depois que o candidato tentar fazer, quando a sua contribuição para um repositório de código aberto já é a demonstração que você sabe fazer isso. Ou seja, não dá para esconder, faz parte do seu currículo.

E essa questão de ser convidado a contribuir também mostra também outro aspecto do open source. O software hoje é bastante complexo, então não caberia na cabeça de uma pessoa só. Mas em 1972 ele já não cabia: quando o pioneiro da computação Edsger Dijkstra foi dar uma palestra na ACM nos Estados Unidos, lá ele disse: “software moderno não cabe na cabeça de um programador”. Imagine hoje em dia um software distribuído com microsserviços. Ninguém é capaz de ter tudo na cabeça! Todo software é desenvolvido em equipe, e equipes que muitas vezes não estão no mesmo espaço físico, mas espalhadas pelo mundo afora.

Então você tem que saber conversar, saber dialogar, saber apresentar suas propostas e, principalmente, aceitar críticas. E saber também que tem sempre gente que é melhor do que você. Só que a pessoa que é melhor que você pode te ensinar a ser melhor do que você é hoje, portanto, acaba que você ganha mestres gratuitamente quando trabalha em projetos open source.

Agora, voltando ao nosso debate aqui: Douglas, se hoje você fosse dar uma dica para a pessoa que vai começar a trabalhar com código aberto, qual seria o comportamento que ela deveria ter diante da comunidade? Porque às vezes surgem pessoas que chegam no projeto e dizem: “vocês têm que fazer tal coisa aí nesse software”; assim, como se fosse um pedido, ou mesmo dando uma “uma ordem de serviço” para a comunidade; quando não é bem assim, não é mesmo? Daí a pessoa pode ouvir de volta um “porque você mesmo não faz”? E tá instaurado o mal-entendido: a pessoa que fez o “pedido” pode reagir de uma forma talvez mais reativa, algo como: “esse cara acho que não gostou do meu pedido, tá falando para eu fazer, quando eu só pedi um negocinho ali, que má vontade de fazer…”. Então, queria ouvir de vocês o que acham disso.

Douglas Iacovelli: Ótimo tópico! Eu acho que quando eu ouvi algo assim por um breve momento eu também pensei: “poxa vida, será que ele tá sendo passivo-agressivo”? Mas depois percebi que não, na real é realmente o lance da contribuição. E comecei a refletir sobre isso, a pessoa que pediu para eu fazer o código e contribuir deve ter uma série de outras responsabilidades e coisas muito mais complexas que ela está resolvendo que vão ter muito mais impacto em todo o resto do código que já existe ali, então eu fiquei pensando: “bom, se essa pessoa incentivou que eu fizesse, provavelmente não é algo tão complicado, ou talvez ela tenha me lançado um desafio”. E isso fez muito sentido na minha cabeça, e pensei: “quer saber? vou aceitar o desafio, e vou tentar resolver eu mesmo esse problema”.

Então é uma coisa realmente de poder contribuir e receber de volta na comunidade open source que eu acho incrível também. E, como dica, eu daria: em primeiro lugar, sempre assuma que a pessoa - o “outro lado” - tem uma intenção positiva, e você, da mesma forma, também deve assumir e fazer isso. Então, por exemplo, você vai lá e comenta: “preciso de uma melhoria aqui nesse código aberto”. Mas, antes de qualquer coisa, precisa procurar e ver se já existe algum código que resolva o seu problema, e se não existir, procurar nas issues que já estão relatadas para ver se alguém já identificou um problema relacionado ao seu; só depois disso partir de fato para abrir uma nova issue ou tentar até contribuir com a discussão. Você não precisa programar, necessariamente. Você pode contribuir na discussão, falar em qual caso surge um problema, ajudar a criar um projeto de exemplo, enfim, todas essas coisas são formas de contribuir também. Então acho que tem várias formas legais da pessoa começar a colaborar que não seja só programando.

Flávio Lisboa: E você, Gabriel?

Gabriel Araújo: Meu ponto de vista é bem assim: para quem está começando, em primeiro lugar, não tenha medo de olhar o código. Se você tem a oportunidade de trabalhar com o código que é aberto, assim, vai fundo! Procure entender o que está acontecendo; claro, tem sempre o principal gatilho: “estou com um problema com isso aqui e preciso resolver…”. Eu tive bastante medo de olhar para dentro do código, então, quando quebrei essa barreira do “medo de olhar e não vou entender”, ou então “vou olhar e vou me decepcionar…” foi essencial, porque pelo menos eu estou tentando, ou seja, ao invés de ser só uma pessoa que está solicitando uma mudança, estou procurando ser o agente dessa mudança… e isso foi muito legal.

E eu vejo uma revisão de PR (pull request) como um presente que a pessoa te dá - e aí quem é dev vai entender - porque ela parou para ver o seu código e verificar se faz sentido ou não, e também para te dar feedbacks sobre esse código. E pra mim, que trabalho com Flutter diretamente, eu ficaria muito feliz se um código meu que fosse revisado pelo time que faz a linguagem. Isso seria o máximo para mim! Então essa coisa de o quanto você aprende também fazendo isso, essa exposição que você está se submetendo pode trazer muita coisa positiva para você se souber lidar bem com ela. Acho que é muito importante também o que o Douglas falou de sempre assumir que a pessoa está com boas intenções. Eu vejo na comunidade que tem muita gente querendo ajudar, e isso é super legal e traz muita coisa positiva para a comunidade, para você mesmo, para quem está consultando e assim vai.

Douglas Iacovelli: Falando em olhar o código aberto e contribuir sem medo, tenho algumas dicas para quem quer começar e nunca fez isso. Começar com o código de uma biblioteca muito simples é uma delas: tá cheio de biblioteca super utilizada, que muita gente usa, e que o código não é muito grande - às vezes é um arquivo só com 100 linhas de código. E, além disso, também tem outra coisa que eu acho que é muito interessante: nos repositórios,  existem alguns filtros das issues que o usuário consegue aplicar, e que contam com tags que acabam sendo boas “primeiras issues” para você atacar, principalmente para pessoas que não estão familizarizadas com aquele determinado código ou framework.

Em outros casos, é fácil de olhar e começar direto pela documentação, mas também, se parar para pensar, o código pode ser gigantesco e ter muita coisa nele; e daí se você, além de programar, também for lá e fizer a documentação, acaba sendo muito trabalho para uma pessoa só. Então, se buscar dividir isso, por exemplo, primeiro você faz o código e depois pede ajuda da comunidade para documentar… também é uma coisa super importante, porque todo mundo precisa da documentação. Então fica aí mais uma dica para quem quer começar.

Tópico 3: Boas práticas e engajamento

Flávio Lisboa: Eu trabalhei no projeto de código aberto Tine 2.0, que acabou me levando com alguns colegas para Alemanha visitar a empresa METAWAYS Infosystems GmbH, que foi quem criou o framework Tine 2.0. E durante uma das reuniões que tivemos por lá, eles comentaram alguns exemplos de contribuição - bons e maus. Um colega da nossa equipe no Brasil foi citado como um bom exemplo e outro como mau exemplo, ao que um deles (da equipe de criação do framework) comentou: “isso aqui é mau exemplo”, porque a pessoa no caso simplesmente mandou um commit com um código só, sem falar nada; enquanto que o outro - o “bom” exemplo - acabou enviando screenshots, debateu e justificou a mudança dele, bem como qual vantagem iria trazer para os usuários do sistema.

Então assim, o que eu vejo é que algumas pessoas têm dificuldade de entender que o software de código aberto é um negócio para ser usado por pessoas do mundo todo que, por sua vez, possuem necessidades de negócio diferentes, porém com um núcleo comum de problemas, e as coisas imediatas que têm consenso são aquelas que são os problemas comuns; mas também por vezes surge alguma necessidade que é local e muito particular. E aí não tem telepatia: a pessoa tem que chegar e se manifestar: “olha, eu quero essa mudança aqui porque ela vai ajudar nisso aqui, ou seja, tem que descrever e explicar o problema. Não basta chegar com o código-fonte ali e mandar ‘tá aqui minha contribuição’”.

Na verdade, você precisa “vender” sua contribuição, acho que essa também é uma dificuldade geral. Então vou aproveitar para compartilhar uma dica também, essa é gratuita inclusive, que é um livro do Karl Fogel chamado “Producing FOSS”. Nele, o Karl comenta sua experiência sobre como criar um software de código aberto, e não somente isso, mas também como criar a comunidade em torno dele. Porque você pode pensar: “existe um software disponível que eu posso baixar e utilizar, se ele não me atende 100%, eu vou lá e altero, faço o restante do que falta”.

Agora, tem uma outra abordagem também, que consiste em abrir uma parte, ou quem sabe todo o código-fonte de um dos projetos do usuário, com vistas a captar inovação… porque não? Claro que aqui não estou querendo dizer que você vai pegar todos os códigos-fonte da sua empresa e abrir para a geral, afinal, é preciso pensar estrategicamente também. Tem coisas que são segredo de negócio, e portanto você vai deixar fechado; mas também tem outras em que é possível deixar aberto para a comunidade poder contribuir. Você pode por exemplo pensar na sua arquitetura, e separar as partes que podem ser abertas e as partes que permanecerão fechadas. Mas aí tem uma outra questão: ao abrir o código-fonte, você pode deixar lá no repositório e simplesmente não aparecer ninguém - só aquele som do grilinho mesmo - e absolutamente nenhuma contribuição. Agora, porque será que isso pode acontecer também?

Porque é preciso criar engajamento também, e aprender a vender o seu software. Vejamos por exemplo a questão da documentação: existe software que é muito bom mas tem uma documentação ruim; e, nestes casos, ele acaba sendo superado por um software que não é tão bom mas que possui uma documentação excelente, aquela que pega o usuário de jeito e ensina o passo-a-passo do que ele precisa fazer para chegar lá. Então a documentação é um negócio importante, é realmente um caminho que também dá para começar a contribuir, porque ao documentar para estudar você vai entender melhor aquilo para depois poder talvez realmente contribuir com o código-fonte. No livro que citei acima o Karl Fogel comenta a experiência dele, e dá o conselho sobre como você pode montar uma infraestrutura para um “código aberto de sucesso”.

Também quero comentar o outro lado das coisas, as que acabam dando errado. No meu projeto de pesquisa do mestrado, analiso um projeto de código aberto que não deu certo. Ele teve o momento dele, de superar um software hoje largamente utilizado, que é o Ansible, da RedHat, um software de automação de infraestrutura; esse software que eu comento na minha dissertação surgiu antes do Ansible, e foi colocado em um repositório de código aberto, mas mas acabou tendo assim zero contribuição, ou seja, ele ficou só com a “euquipe” do programador que o desenvolveu.

Ainda assim foi um caso interessante porque foi uma perda completa de oportunidade. E a razão para tanto é que simplesmente não teve engajamento, não teve uma estrutura de gerar comunidade e trazer as pessoas para dentro. Não teve documentação suficiente que permitisse a compreensão do uso do software. Mas esse caso serve para ilustrar que não adianta só disponibilizar o código e esperar acontecer uma mágica para que as pessoas venham contribuir.

Tópico 4: Software livre é seguro mesmo?

Flávio Lisboa: Gostaria de entrar agora em um assunto que talvez seja um pouco polêmico, até porque aconteceram algumas coisas nas bibliotecas recentemente que dizem respeito à parte de segurança. Daí a galera pode pensar: “ah, sabia, esse negócio de software livre não é confiável e tal…” mas, calma lá. Eu até separei o repositório do Flutter aqui, porque assim como todos os projetos hospedados no GitHub que são de código aberto, você vai observar ao lado direito da página onde fica o repositório que tem uma informaçãozinha lá que diz respeito à licença do software.

E a licença é um documento que acompanha cada software, sendo que no caso do Flutter é a BSD3.  E quando você abre esse documento, aparecem alguns itens ali: permissões, uso comercial, modificação etc. Só que ali em limitações aparece que não tem garantia… e aí você se pergunta: “opa, peraí, como vou usar esse negócio se não tem garantia? Se vou usar na minha empresa, quem vai me dar suporte quando precisar”?  Então essa é uma questão que eu gostaria que vocês abordassem, começando pelo Douglas: como você entende essa questão da falta de garantia aparente do software livre? E essa questão da segurança, onde o código-fonte fica disponível para qualquer pessoa acessar, e eventualmente explorar vulnerabilidades também…

Douglas Iacovelli: Ótimos pontos, porque de fato o código-livre é um divisor de águas para muitas pessoas, para muitas empresas principalmente. O código aberto não tem normalmente nenhum tipo de garantia, então é como diz aquele velho ditado que a gente brinca: “la garantia soy jo”. Se já está tudo funcionando lá no repositório, maraviha, mas a verdade é que ninguém tem nenhuma obrigação de fazer com que o código funcione, muito menos de de dar segurança para esse código.

Mas tem uma questão de ética subjacente aí, onde procuramos escrever um código que seja seguro - ou pelo menos esperamos que as pessoas tentem fazer código seguro; no entanto, é muito diferente de uma empresa, de onde você compra um software. Essa empresa tem um acordo comercial, ou seja, você está pagando pelo software. Logo, existem coisas que precisam ser cumpridas, e até como diferencial de negócio a empresa pode oferecer suporte, segurança, garantia etc, entre outros pontos.

Eu observei alguns casos recentes que aconteceram, por exemplo, o do Log4j. Basicamente, o Log4j  é uma biblioteca de log do Java, então é uma coisa muito básica, é feita e mantida pela Apache, que é uma Fundação gigantesca e já existe há muitos anos; acontece que muitas empresas usam o sistema de log do Log4j, e no começo de dezembro passado acabaram descobrindo ali uma falha de segurança. Era uma falha em que, a partir do momento que é descoberta, todo mundo consegue aproveitar e explorar as vulnerabilidades, sendo que o código dela é aberto.

Daí vem o questionamento: porque o código é aberto fica mais fácil de explorar suas vulnerabilidades? A resposta é: provavelmente sim. Por outro lado, também é mais fácil de evitar as vulnerabilidades. Ou seja, têm muitas pessoas usando esse código, portanto, também muitas pessoas de olho nele. Então é uma faca de dois gumes: pode ser para o bem e pode ser para o mal. E aí aconteceu que a falha chegou ao conhecimento dos mantenedores oficiais, e eles lançaram uma atualização que corrigia de fato os problemas. Mas, para vocês verem, é uma coisa que é difícil de controlar. Mesmo para um código que já era usado há muito tempo, ninguém até então tinha pego essa vulnerabilidade, ou pelo menos não tinha ficado publicamente disponível durante muito tempo.

Gabriel Araújo: Sobre esse caso, uma discussão que surgiu foi quem seria responsável por corrigir a falha de segurança do Log4j. Seria a pessoa que é dona do repositório? A Apache Foundation? Ou a comunidade deveria se unir para fazer essa correção o mais rápido possível? E aí rolou esse debate, por isso até que o open source ganhou um pouquinho mais de relevância nesses tempos, porque é uma coisa que todo mundo ficou correndo atrás do relógio para não deixar ter vazamento de informações etc, e no final surge a discussão: mas, de quem é a responsabilidade?

E aí acho que é até legal a gente falar um pouquinho sobre isso porque não sei, para mim se o software é livre e todo o código está lá, acho que a responsabilidade é da comunidade fazer a manutenção do software; se tem um caso desse que está afetando muita gente, vamos nós como comunidade fazer/corrigir. E quem sabe até colocar as pessoas que estão trabalhando nas empresas “Fortune 500” para resolver essa vulnerabilidade. Afinal, como tem muitas empresas grandes que fazem uso do código, elas também deveriam ajudar, já que podem se prejudicar mais seriamente. Então essa é uma discussão que é bem legal, sobre de quem é a responsabilidade (da manutenção de segurança) do software livre.

Douglas Iacovelli: Nossa, de fato. Inclusive isso que você citou das 500 maiores empresas dos Estados Unidos… lembrei de outro caso curioso que foi o do faker.js e do colors.js; para quem usa bastante biblioteca Javascript já deve ter ouvido falar disso também. O que aconteceu: o Marak Squires, a pessoa por trás dos códigos do faker.js e do colors.js, introduziu um bug aparentemente intencional - digo aparentemente porque não se tem certeza se foi intencional ou não - e esse bug fazia com que houvesse um loop na aplicação, de tal forma que ela passava a imprimir indefinidamente vários símbolos estranhos e tal. Acontece que o faker.js e colors.js são usados por muitas aplicações, têm mais de milhões de downloads, não é pouca coisa… então acabou quebrando um sem número de aplicações que usava os códigos desenvolvidos por ele.

E aí começaram a tentar entender o que realmente tinha acontecido. Até que viram que no final de 2020 ele tinha postado que não iria mais dar suporte para essas bibliotecas, porque ele pensava o seguinte: porque eu tenho que oferecer suporte para essas bibliotecas enquanto as 500 maiores empresas dos Estados Unidos, que ganham bilhões (com isso) não estão me pagando nada? No que acabou gerando uma discussão muito interessante sobre “e aí, será que ele deveria receber dinheiro pelo trabalho que está fazendo? Será que as empresas deveriam contribuir mais?” Enfim, essa discussão vai muito longe mas e é um tema muito interessante, mas que também não dá o direito da pessoa ir lá e quebrar as bibliotecas para que todo mundo se ferre, né?

Flávio Lisboa: É, isso é um problema que pode acontecer não só com software aberto, não é mesmo? Talvez pelo fato de ser aberto haja uma amplitude maior. Mas imagina um cenário em que a pessoa está insatisfeita com a empresa e aproveita que tem acesso a alguma coisa ali e sabota. Também é algo que pode acontecer. Inclusive, essa é uma questão geral na área de segurança de TI: existe a visão “romântica” da segurança na área de TI, aquela que a gente vê em filmes e séries de ficção; e tem a visão real: na visão romântica, o cara pensa assim: “nossa, tem aqui um sistema com uma alta criptografia, então o hacker vai criar um cluster de computadores que fica rodando programas para quebrar a criptografia e invadir o sistema”; quando, na verdade, é mais fácil sequestrar alguém e literalmente bater na pessoa até ela falar a senha do sistema.

Não que chegue a esse extremo, é claro, mas tem coisas que são bobas: às vezes alguém pode fazer uma grande besteira e colocar em um post-it o dado da senha dele na tela do computador, daí alguém passa no corredor e vê; ou, então, a pessoa acaba falando de coisas sensíveis do sistema em uma conversa de bar. Em outras palavras, não precisa de nenhum conhecimento avançado em computação para poder ter acesso a alguma máquina com informações… trata-se de engenharia social mesmo. Também existem pessoas que agem de má fé, e sempre tem algum louco que pode fazer alguma coisa indevida mesmo.

Mas, no caso do código aberto, talvez uma das vantagens é você conseguir verificar o que o cara fez. Essa é uma coisa interessante: a rastreabilidade. Então o cara vai lá e faz uma alteração no código, essa alteração pode ser rastreada: você sabe quem fez, o que fez, quando fez. Você tem os commits, você tem as alterações, esse controle comunitário do código permite também fazer uma auditoria. Só que, claro, é preciso haver uma organização, uma disciplina que faça com que as pessoas revisem esse código. E aí não é só manter o código-fonte hospedado lá, ele precisaria passar por um processo de controle de qualidade de código, que é uma coisa bastante importante.

Talvez essa seja uma necessidade capaz de evitar problemas, ou seja, uma estrutura onde haja revisão não somente para o código funcionar - até porque não estou falando em teste automatizado para ver se o software funciona - mas de fazer uma inspeção geral do código justamente para ver se não tem vulnerabilidade, justamente para assegurar que ninguém faça algo de má fé. Eu tenho uma experiência muito boa com um colega meu, vou até citar o nome dele porque esse cara é fantástico: o nome dele é Cassiano, ele é de Porto Alegre.

Acho que foi o melhor Git Master com quem eu tive o prazer de trabalhar, porque ele é o cara que garantia mesmo que não houvesse uma espécie de “tráfico de código”. E o que eu quero dizer com tráfico de código? Basicamente, quando você vai fazer uma alteração no código-fonte, pelos princípios ágeis, essa alteração tem que ser mínima, ela tem que  atender ao problema que você deseja resolver. Mas aí uma pessoa pode querer aproveitar essa mudança no código para alterar mais algumas outras coisinhas, e aí aquele commit que devia ter três arquivos alterados, aparece com vinte arquivos alterados.

E aí quando surge um problema, você vai investigar a causa e vê que tem lá um monte de arquivo alterado e aquele negócio atrapalha para descobrir o que foi realmente modificado; então são coisas que, bem, se você quer resolver o problema, então você vai mudar só o que diz respeito a esse problema específico. Ou seja, outras mudanças relacionadas vão requerer outros commits, e assim sucessivamente. Então, na prática, você tem que ter os papéis das pessoas que trabalham com qualidade de software. O Gabriel até comentou que é fã dos commits pequenos, e eu acho que é bem por aí mesmo: você tem que fazer alterações pequenas que sejam rastreáveis e controláveis para poder ter auditoria.

Então a questão da segurança passa por todos esses pontos. Já a garantia, realmente, no caso do software de código aberto, o código está aberto justamente para ser compartilhado, e a garantia é você, que está assumindo aquele código. Isso não impede que existam empresas que ofereçam suporte, e elas existem. Por exemplo, a RedHat é uma delas: eles trabalham com código aberto e vendem suporte técnico, mas tem outras empresas que também vendem suporte.

Então, se você vai usar um software de código aberto, você não vai ficar necessariamente sem suporte: você deve pesquisar, por exemplo, quem o utiliza no momento; ou ainda: quem o mantém? Por exemplo, a Apache Software Foundation é uma grande organização com projetos enormes de software aberto que são usados pelas “big techs”, quais sejam: Amazon, Google, Facebook, Microsoft… todas as nuvens disponibilizadas por essas organizações usam software aberto. As ferramentas para cloud que elas oferecem são em sua maioria software de código aberto que fazem parte do serviço disponível aos usuários.

E essas mega organizações também contribuem com software aberto, porque elas precisam desses serviços - elas vendem “software como serviço” (o famoso SaaS). Então daí você já conclui que tem gente grande envolvida nesses projetos de software livre. Daí você pode concluir que talvez seja interessante adotá-los, porque tem gente muito séria contribuindo. E essa é só uma dica. Outra dica diz respeito à comunidade: não apenas ao tamanho da comunidade envolvida, como também a qualidade das pessoas que estão envolvidas nos projetos open source.

Existem várias fundações hoje em dia que trabalham com software de código aberto: além da Apache Software Foundation, que mencionei acima, tem também a Eclipse Foundation,  a Linux Foundation, enfim, todas essas fundações têm sites que você pode pesquisar e dar uma boa olhada nos projetos. Daí você já pode deduzir quem está investindo no software do seu interesse, bem como as empresas que estão dando suporte. Por tudo isso, você sabe que não está totalmente “refém” da situação. Ou seja: não é porque na licença diz que está sem garantia que você vai ficar sem gente que possa te oferecer um bom suporte.

Além disso, outra coisa boa de pesquisar são as certificações: isso porque há tecnologias que são abertas, mas elas possuem certificações. Ou seja, o desenvolvedor tem que fazer uma prova (difícil, por sinal) para tirar uma certificação e mostrar que ele entende muito bem daquilo - obviamente, essa também é uma pessoa qualificada para dar suporte naquela tecnologia específica que você procura. O que confere também uma segurança maior já que haverá gente qualificada de verdade para dar o suporte adequado.

Agora queria aproveitar para perguntar aos convidados se tem mais alguma coisa a acrescentar sobre essa questão da confiança no software livre. Eu gostaria que vocês falassem do Flutter, por exemplo. Ele começou com o Google, certo?

Tópico 5: Flutter

Gabriel Araújo: Boa, vamos lá! Eu vou até compartilhar minha tela aqui só para mostrar para você algumas das coisas que a gente realmente olha quando avaliamos se vamos incluir ou não uma biblioteca no nosso projeto. Aqui estamos no site pub.dev, que é um site do Flutter mesmo, para as bibliotecas que temos e as que vamos usar, e aqui geralmente é o primeiro lugar que a gente observa antes de fazer alguma coisa. Por exemplo, quando precisamos criar algo relacionado com localização ou notificação, é aqui geralmente onde vamos procurar se existe alguma coisa que já foi feita que nos interessa.

E aí temos alguns tópicos bem interessantes para avaliar: o primeiro deles é verificar há quanto tempo exista uma nova versão dessa biblioteca; esse é um indicativo para a gente de que, por exemplo, essa biblioteca está tendo manutenção constante. Tem alguém de olho nela? A comunidade está engajada nisso? O Flutter mudou agora para null safety, então observamos também se tem null safety. Essas partes são bem legais, então quando você usa uma uma biblioteca, pode dar um like nela: esse é um indicador de quantas pessoas estão usando e como está sendo a experiência delas.

Outra coisa interessante de olhar são os pub points. É um checklist que vai apontar se uma lib tem teste, ou ainda se está com a documentação clara e faz o que realmente promete.  Isso é bem legal para identificarmos a confiabilidade e a popularidade da lib também. Outro ponto importante são as issues: observe se tem muitas issues abertas, e veja também qual é o tempo de resposta geral delas. Esse é um indicativo de que tem gente trabalhando nessa lib para fazer com que ela funcione. Às vezes ter muitas issues não é o problema: isso quer dizer que tem muita gente utilizando, fazendo acontecer e tornando essa lib ainda melhor. Essas são algumas das coisas que a gente observa.

A documentação nessa lib eu acho sensacional porque além de ter uma espécie de sumário, ela apresenta screenshots, ensina como fazer o setup para Android e iOS, tem app de exemplo, enfim, tem tudo o que a gente pode precisar para usar no projeto e saber que vai funcionar. Então essas são algumas das coisas que a gente analisa para poder julgar se a lib vai fazer sentido ou não em um determinado projeto. Douglas, você me ensinou isso tudo, se tiver algo mais a acrescentar…

Douglas Iacovelli: Você falou tudo! Mas, além disso, eu só queria acrescentar que, recentemente, tivemos que implementar a integração com uma biblioteca de terceiro e não tinha nada pronto no Flutter para fazer isso. A gente não sabia muito bem a parte do iOS, então quando usamos o Flutter - pra quem não sabe, vou falar bem brevemente - a gente tem o código Flutter e a gente tem o código Android, e também o código iOS; fora isso, tem outras plataformas que dão suporte também, mas o ponto é: a gente precisa de alguma forma interagir com esses códigos nativos e não sabíamos como mexer direito no iOS por falta de conhecimento dentro do time.

No caso, essa biblioteca que o Gabriel mostrou ajudou muita gente porque o código é aberto, então foi possível olharmos partes de como foi feita aquela biblioteca, e como eles resolveram alguns problemas muito específicos de iOS. Isso porque o código está aberto. Se fosse fechado, provavelmente demoraria muito mais tempo. Então acabou que economizamos tempo porque a lib já estava feita, podíamos usar em outros casos também, e porque foi possível usar o código dela como referência. Agora, voltando para o ponto que o Flávio tinha perguntado, sobre o Google e o Flutter. O Google de fato dá suporte ao Flutter, tem um time enorme cuidando disso, eles gastam muito dinheiro cuidando do Flutter. E óbvio, toda comunidade também ajuda sem receber nada por isso, mas a gente recebe de volta aquilo que a gente falou bem no comecinho da conversa (ou seja, a mentoria). Flávio, tem algo mais específico que você quer que a gente entre aqui?

Tópico 6: Participação da comunidade vs empresas mais conscientes da importância do código open source

Flávio Lisboa: Acho que é interessante comentarmos também sobre a participação das pessoas nas comunidades, já que o nosso trabalho não se restringe somente à melhoria de código-fonte no GitHub, certo?

Douglas Iacovelli: Claro! Estamos “puxando a sardinha” para o lado do Flutter porque é a nossa especialidade, mas isso serve para qualquer tipo de comunidade. O Flutter, por exemplo, eu reparei recentemente que quando acesso alguma biblioteca, vejo alguém criando ou respondendo uma issue; daí sempre vou no perfil da pessoa quando o nome parece brasileiro… e dito e feito: quase sempre é um brasileiro comentando mesmo. Então, por exemplo, dá para ver que a comunidade do Flutter cresceu muito no Brasil.

O RubyOnRails é muito forte na comunidade brasileira também. Só a título de curiosidade, para quem é do Rails, uma biblioteca muito usada é o devise. Essa biblioteca foi criada por desenvolvedores de uma empresa brasileira. E essa biblioteca é usada hoje em muitas aplicações, porque é a forma mais básica de se fazer uma autenticação no Rails. Então dá para ver que a comunidade brasileira é muito forte; a gente também tem uma síndrome de vira-lata enorme mas a verdade é que os brasileiros programam tão bem ou melhor ainda que os desenvolvedores de outros países. Esse é só um dos pontos, mas a gente também têm muitos eventos como o Flávio falou. O Google por exemplo, eu sei que eles têm até orçamento para que a comunidade faça eventos e continue fomentando conhecimento, trazendo mais pessoas, ajudando os desenvolvedores a criar código, compartilhar, enfim, nunca é só o código, é sempre o ecossistema, a comunidade inteira que existe… que é magnífica.

Flávio Lisboa: Muito bom. Eu também faço parte da comunidade PHP Brasil, sou palestrante na PHP Conference há vários anos e é muito interessante essa oportunidade de conseguir interagir. Você vai ao evento e conhece pessoas novas, pessoas que às vezes resolvem um problema que você tava ali perseguindo há tempos, assiste uma apresentação, às vezes só uma parte dela e já consegue te ajudar a pensar de uma forma diferente que não tinha pensado antes, enfim, sempre descobre alguma coisa nova. Mas se eu conseguir realmente ter a oportunidade de conhecer pontos de vista e abordagens diferentes - porque cada empresa está focada no seu negócio, tem seus contextos de problemas, e às vezes tem coisa você não vai saber porque não vai passar por aqueles problemas - mas quando para para ouvir a experiência de uma outra pessoa, acaba tendo novas ideias para fazer alguma coisa diferente, ou até para melhorar aquilo que você já tem, ou mesmo evitar um problema nem tinha percebido que poderia ter.

E aproveitar para falar mais amplamente sobre software de código aberto também, é claro! Há algum tempo tenho participado de outro evento, chamado ConFLOSS, que é organizado por um grande colega, o mestre Er Galvão. É uma conferência geral sobre código aberto e todas as tecnologias que envolvem servidores de aplicação, banco de dados, sistema operacional, software para desenvolvimento mobile etc; além de tudo isso, também aborda os aspectos humanos do software de código aberto, porque afinal de contas, o software é feito por pessoas que pensam, tem que se relacionar, e também tem que ter algumas competências humanas para poder trabalhar em equipe, como já comentamos anteriormente.

Hoje em dia uma competência adicional do profissional de TI, chamada também de “soft skill”, é justamente saber dialogar e chegar a um consenso enquanto equipe. Já não dá mais para ter aquela visão romântica do desenvolvedor como o cara que trabalha da meia-noite às 5h comendo pizza e tomando Coca-Cola, e que resolve sozinho as coisas… aí lá pelas 2h30 da madrugada ele dá um grito “consegui!!! compilou”!!!! Definitivamente, não é assim que funciona, salvo talvez em alguns casos muito excepcionais. Então você tem que trabalhar de forma integrada, e fazer um código que seja “habitável” e que outras pessoas consigam também dar conta, porque se você sair daquele projeto, outra pessoa vai assumir o seu papel e vai precisar entender o que você fez para tentar absorver aquilo ali o mais rápido possível.

A pessoa que assumir seu código vai ter um tempo para poder aprender, mas esse tempo pode ser reduzido: se tiver uma boa documentação, se o código for bem estruturado… se não for um “campeonato de programação de uma linha”, já que tem gente que quer botar tudo em uma linha só para economizar as linhas do editor de texto. Brincadeiras à parte, tem que pensar em fazer um código que seja na linha de uma casa que você consegue andar sem tropeçar pelo caminho.

Tem um problema clássico da engenharia de software, que o Frederick Brooks trouxe lá dos anos 1970, e que ainda hoje acontece, que é o problema do software ser “parecido” com a ideia ter filhos. É mais ou menos assim: uma mulher, em nove meses, pode gestar e dar a luz a um bebê; mas se você colocar nove mulheres (gestantes) juntas, elas não serão capazes de gerar um bebê em apenas um mês. Da mesma forma, transportando para o desenvolvimento de software, não é porque o projeto está atrasado que colocando mais duas pessoas ele será finalizado em um mês.

Aliás, pode até acabar atrasando ainda mais, porque, na prática, a depender da estrutura que existe no projeto, o desenvolvedor vai cair de paraquedas. Daí, assim: ele pode conhecer a linguagem de programação? Pode. Pode ter tido experiência? Pode. Mas de qualquer maneira ele terá que se ambientar ao projeto, à estrutura, aos padrões que são utilizados… e até ele entender como tudo funciona, pronto… já acabou o projeto. Então tudo isso só para dizer que a gestão do conhecimento do negócio é também fundamental para o sucesso do projeto.

E eu acho que, sob esse aspecto, trabalhar com código aberto ajuda um pouco, porque você se obriga a ter que escrever as coisas, a ter que conversar, muitas vezes com uma pessoa que está muito distante de você. Eu acho assim, do que os convidados falaram até agora, a gente pode ver que o software de código aberto é um negócio que funciona! Ele é usado não por qualquer pessoa, é usado por grandes empresas, está espalhado pelo mundo, é utilizado desde o celular que você carrega no bolso - dependendo da plataforma que você utiliza - até o robozinho que foi parar em Marte. Tem software de código aberto espalhado pelo mundo que você pode interagir, pode contribuir e o melhor de tudo: isso pode servir para alavancar a sua carreira.

Agora, acho que uma coisa interessante seria a gente entender melhor a questão de como internalizar isso na cultura de uma empresa também. Então eu queria perguntar isso para o Douglas, essa questão de poder colocar uma parte do nosso código como open source… será que isso inicialmente é bem visto, mal visto? Muitas empresas podem achar (erroneamente) que você está “entregando de graça o nosso produto, então não vamos abrir nada aqui, é tudo nosso”! Enfim, como é que você vê essa questão?

Douglas Iacovelli: Eu vejo da seguinte forma: acho que depende muito da empresa, mas vou citar alguns exemplos aqui mais famosos. O Nubank: é uma empresa muito conhecida por fazer código de excelente qualidade e eles já abriram alguns códigos deles; então só estou citando como exemplo porque é uma empresa muito grande e famosa, mas além deles outras empresas também fazem isso. Então, até que ponto o código é de fato uma propriedade da empresa a ponto de ser um diferencial de outra empresa? Explico: às vezes, o pedaço do código que a gente pensa em abrir não tem nada a ver com a regra de negócio da empresa. Ou seja, a gente está falando de uma coisa que pode ser muito genérica e que funcionaria para qualquer empresa, o que não quer dizer que se outra empresa pegar aquele código ela vai virar, por exemplo, o novo Nubank. Não… não tem nada a ver com isso.

Além disso, tem um benefício que talvez algumas empresas ainda não enxerguem ou algumas pessoas não percebam, que é o seguinte: quando você tem um código aberto e é uma empresa que está abrindo esse código, ela na verdade está se conectando muito mais com a comunidade de desenvolvedores ao redor desse código. Lembrei de outro caso também, o da ZUP Innovation. Um amigo que trabalhou lá, contou que eles fizeram um pedaço de código e o mantiveram aberto. Resultado: aquele código foi visto por milhares de desenvolvedores aqui do Brasil e de fora do país também.

Hoje em dia, o mercado de tecnologia é bastante concorrido. E por ser tão concorrido, você como empresa, ou como dono de empresa, tem que começar a pensar: como é possível atrair e reter talentos? Então, esses são os motivos… você conseguir se mostrar para os desenvolvedores como uma empresa de tecnologia e que gosta disso. Porque hoje a gente sabe que muitos desenvolvedores também valorizam isso. Além do mais, tem outro ponto que eu acho que é super importante: na Revelo, eu não fui a primeira pessoa a contribuir com open source.

Tiveram algumas outras pessoas: o Rodolfo, o Radamés, que é um exemplo recente, eu, que vim depois… e sempre que entrevistamos alguém para uma vaga, a gente diz: tivemos pessoas aqui que fizeram commits no Rails, tivemos pessoas que fizeram commits no Flutter, em bibliotecas que são utilizadas no Flutter e em outros aplicativos. Então, a gente chama a pessoa de uma outra forma, a gente conquista ela; porque, de uma outra maneira, estamos falando assim: “temos pessoas muito boas aqui dentro, e aqui você vai aprender muito com a gente também”. Então isso são só algumas das coisas que fazem com que brilhem os olhos dos desenvolvedores quando tem código aberto na história.

Gabriel Araújo: Acho que até na parte da contribuição para código aberto, o caso que a gente passou junto: tínhamos um problema, gastamos nosso tempo para contribuir para um código open source, mas isso resolveu o problema também que tínhamos para a tarefa que precisávamos entregar, entende? Então, mesmo que a empresa não queira dividir uma parte do código dela, liberar tempo para que os seus profissionais possam pensar em soluções para códigos que já existem ou pensar nas notificações que eles possam fazer para um outro código, também pode ser benéfico para a empresa. Então a gente conseguiu resolver problemas que a gente tinha dentro da Revelo contribuindo para o open source.

Flávio Lisboa: Muito bom! Existem vários softwares de infraestrutura que são usados por muitas empresas e que são concorrentes entre si - e elas contribuem para o mesmo software. Servidores de web, servidor de aplicação… você pega a lista de contribuidores e pensa: poxa, essas empresas são concorrentes, mas elas estão juntas aqui porquê? E a resposta é: porque aquele problema é comum para essas empresas. Elas podem até ser concorrentes, mas estão melhorando um produto que ambas utilizam, e aí naquele naquele aspecto elas podem colaborar. Ou seja, você pode concorrer e colaborar simultaneamente.

E uma coisa interessante do código aberto é justamente essa possibilidade que você tem de poder (re)aproveitar as coisas. Por exemplo, um empreendedor quer montar uma startup, e montar um negócio sempre é complicado no começo: precisa de ferramentas, pessoas, recursos; aí esse empreendedor deseja montar uma solução a partir de uma ideia que ele sabe que é viável na prática, mas se vai fazer do zero, vai levar quantos anos para construir essa solução? Mas o fato é que se você pode partir de uma plataforma que já existe e melhorar, acrescentar recursos, entra na ideia de re-utilizar o software, algo que faz parte da engenharia de software. Ou seja, você pode simplesmente reaproveitar o código existente.

O sonho seria poder montar software como se fosse um Lego: vamos encaixando as pecinhas e em pouco tempo temos um novo software; mas sabemos que na prática não é bem assim que as coisas acontecem. Na prática, você consegue aproveitar bastante coisa com componentes, já que há uma grande disponibilidade de componentes de software para várias linguagens programação. Porém esses componentes geralmente representam uma parte “genérica”, aquela parte que atende a todo mundo. A graça é que você pode colaborar e melhorar, como se fosse uma horta comunitária, onde todo mundo cuida e outras pessoas podem também colher os frutos desse trabalho comunitário.

Tópico 7: Exigências e cuidados para colaborar em projetos open source

Flávio Lisboa: O Raoni levantou um tópico aqui no chat que diz o seguinte: “Certa vez tentei contribuir para um tópico Java relativamente grande e acabei desistindo pois as exigências eram muitas, tais como: primeiro, aceitar determinado código de conduta; depois, os commits tinham que ser assinados; em seguida, necessidade de fazer o fork, com padrões de formatação de código. Não digo que estavam errados, mas no fim das contas resolvi meu problema e acabei não devolvendo para a comunidade. Como equilibrar esse tipo de coisa”? Então, essas exigências realmente podem aparecer para vários projetos porque, justamente, para trabalhar em equipe, você tem que seguir alguns padrões, afinal, todo mundo vai mesclar código no mesmo repositório, não é mesmo? Então, precisa haver um padrão para que esse código seja legível para todos.

Não é só porque você está usando a mesma linguagem de programação que todo mundo vai entender; a questão do código de conduta às vezes aparece porque infelizmente têm pessoas que surgem na comunidade não para ajudar, mas para atrapalhar; e, por conta das falhas de algumas pessoas é preciso adotar algumas regras rígidas, já que alguém fez alguma besteira antes, então isso é compreensível. E aí a questão de fazer um fork primeiro para poder fazer um pull-request depois é uma questão de organização, com o intuito de pegar a sua contribuição e poder fazer uma análise dela primeiro, e aí quando ela estiver amadurecida, será sim aceita. E isso costuma acontecer pelo seguinte: você pode resolver o seu problema de forma particular, e o código funciona, não tenho dúvida disso… mas aí os mantenedores oficiais estão pensando o seguinte: que o seu código tem que resolver o problema de todo mundo. Ou seja, o que importa para eles são os interesses gerais, ou interesses comunitários, não os interesses individuais.

Então você tem essa possibilidade de fazer o fork do software de código aberto e fazer funcionar particularmente no seu caso, mas, é preciso que funcione para todo mundo também. E é por essa razão que você tem que se submeter a esses processos que parecem um pouco mais burocráticos. Mas o fato é que você se acostuma depois, porque quando você entende como funciona da primeira vez, são coisas que acaba fazendo uma vez e depois não precisa mais fazer, é como assinar uma espécie de código de conduta. Eu já fiz isso, e para mais de um projeto. Claro que, como falamos anteriormente, é melhor você começar com coisas menores porque a aceitação é mais rápida. Se você começa com algo mais complexo, acaba sendo mais complicado mesmo, pode ter mais dependências, e também pode afetar outros componentes. Ou seja, se houver uma alteração muito grande poderá afetar muita gente, então é preciso tomar todo o cuidado possível nesses casos.

Douglas Iacovelli: Talvez começar com uma biblioteca menor seja mais interessante, ou uma biblioteca que ainda está com menos contribuições ou com menos código. Não é questão de tamanho, tem bibliotecas e bibliotecas, desenvolvedores e desenvolvedores… eu concordo com tudo o que o Flávio falou, e acho que conforme o projeto vai crescendo você precisa realmente estabelecer algumas regras e deixar de fato o processo mais burocrático. É uma pena, mas precisa, é uma dor necessária. Vou falar uma frase de coaching: “você precisa mudar o mindset”, mas da seguinte forma: quando eu fiz o código do Flutter, criei o código que sabia resolver o problema, mas eu não sabia fazer o teste unitário daquilo.

No entanto, foi uma ótima oportunidade para aprender. Eu disse para eles “olha, eu consigo fazer isso, mas vou precisar de ajuda com teste unitário”. Na hora que eu falei isso eles me responderam assim “Douglas, olha esse pedaço aqui de código, olha esse arquivo específico, que aí você vai ter um exemplo se consegue fazer a partir daí”. E aí eu olhei o exemplo do arquivo, tive que quebrar a cabeça durante umas duas, três horas, mas no final deu tudo certo. É difícil, normalmente não é uma coisa tão trivial; mas às vezes até pode ser. O que eu digo é: tente encarar como uma forma de aprendizado. Mesmo que não dê certo, às vezes o seu pull-request é base para alguém ir lá e escrever o teste. Então não é uma coisa tão ruim assim você fizer uma parte do trabalho e travar porque não sabe ao certo como continuar… você pode e deve pedir ajuda quando sentir que é preciso.

Gabriel Araújo: Eu gosto bastante de padrão e processo, então quando você falou isso eu fiquei pensando principalmente na parte de padrão de formatação de código ser divergente do seu habitual; então o que eu pensaria é: porque será que ele é diferente do meu habitual? Será que eles estão fazendo alguma coisa de uma maneira que é melhor para um app de larga escala e será que não seria interessante eu aprender esse “novo” padrão?

Ou quem sabe até poder adaptar o código da minha empresa e trazer para a comunidade: “Gente, a galera do Java usa esse padrão aqui, porque será que eles usam esse padrão? Vamos ver se ele pode melhorar alguma coisa no nosso projeto”? E aí teria trazido mais uma coisa que aprendi a partir de uma biblioteca open source, mas concordo com tudo o que vocês comentaram.

Flávio Lisboa: Tem outro comentário aqui sobre o distanciamento da regra de negócio e do código. Algo interessante de comentar, inclusive voltando um pouco naquela questão do Log4j e do problema geral que aconteceu por lá: existem problemas que acontecem que não são exclusivos de código aberto, mas sim de arquitetura de software; e o que eu observei com o problema do Log4j de maneira bem ampla é que tinha muito acoplamento direto de aplicações com o Log4j. Isso é algo que, no caso do software em geral, precisamos sempre tomar um certo cuidado, que é acoplar as coisas diretamente e fortemente. E o que eu quero dizer com isso?

Note que o software tem várias partes: a parte das suas regras de negócio, que é sua, fundamental, mas existe também uma série de componentes satélites que orbitam ao redor do núcleo e que te atendem; são serviços que você usa mas que não são coisas que seu cliente pediu, mas você precisa disso para formar a infraestrutura do seu software, como a questão do log, da auditoria etc. E são coisas que você precisa pensar: “nesse momento esse componente me atende bem e é o melhor que eu tenho”. No entanto, a única certeza que a gente tem no mundo do software, quando você acorda e vai trabalhar, é que as coisas vão mudar!

Alguma coisa vai gerar uma mudança, o código vai mudar, e porquê? Porque basicamente os requisitos vão sofrer alteração, a plataforma tecnológica vai mudar, tudo está em evolução constante: as versões do sistema operacional, das bibliotecas, tudo muda o tempo todo. Então você tem que acompanhar, pois daqui a pouco alguma coisa fica incompatível e tem que passar para a próxima versão, porque aquilo não funciona mais; até mesmo a legislação - seja Municipal, Estadual, Federal ou internacional - pode afetar o seu software, já que tem coisas ali que dependem de regras.

E já que é assim, procure se preparar para as mudanças, tente se antecipar a elas. Porque se a única certeza é que elas vão ocorrer, vamos tentar não sofrer e não deixar as coisas para amanhã. A gente sempre fala do futuro no Brasil, e o futuro nunca chega aqui, não é mesmo? Daí você pode pensar: “não estou sendo pago para fazer o software do futuro, mas para fazer o software do presente”. Sim, mas você pode tomar alguns cuidados agora para não passar por um momento de desespero no futuro quando precisar trocar componentes; por exemplo, você pode pensar em criar uma arquitetura que permita uma alteração rápida no momento em que acontecer algum problema mais sério.

Então, em resumo, pelo menos do meu ponto de vista, alguns tipos de componentes eu prefiro não acoplar diretamente às aplicações, mas criar as camadas ali que vão me ajudar futuramente. Por exemplo, no caso do log, tem algumas camadas ali, mas qual é o log realmente? Na verdade, não importa… se eu tiver que colocar até um log-mock para fazer funcionar durante algum tempo e desabilitar imediatamente o componente atual, que seja. Mas que eu não fique desesperado, se algo não estiver funcionando e eu precisar mudar e não conseguir de jeito nenhum. E por que eu não conseguiria? Simples, porque está conectado em duzentos pontos diferentes da aplicação. Em outras palavras, pense que um dado componente possa ter só um pontinho de ligação ali na aplicação de tal forma que seja fácil de desabilitar depois.

Precisamos sempre nos lembrar que código-fonte é algo que só tende a aumentar e ficar mais complicado com o passar do tempo; então tem que dar manutenção nele. Quem não é dev em geral tende a pensar que o software é algo assim “etéreo”, ou seja, ele não se degrada, não se destrói, é tipo “invulnerável”... mas nós que somos devs sabemos que não é bem assim. O software se degrada sim. Só que de uma forma diferente: ele vai ficando cada vez mais complexo, e essa complexidade acaba dificultando a manutenção dele. Por isso tem que ter organização, documentação, arquitetura… para poder manter o software fácil de ser mantido.

Bom, a gente falou bastante aqui dos conceitos, de questões de segurança e das experiências com código aberto. Agora gostaria de entrar aqui na parte final do nosso papo: como é que vocês vêem o futuro do open source?

Douglas Iacovelli: Opa, ótimo! Olha, eu não sou uma pessoa muito visionária, não sou “mãe Diná”, mas tenho algumas ideias. Acho que o open source no futuro de alguma forma vai ter que tentar se precaver dos problemas que passamos atualmente. Por exemplo, a questão do faker.js e do colors.js, será que a gente tem que pensar alguma forma de evitar que o próprio dono da biblioteca de repente não sabote tudo? Talvez a gente tenha que pensar alguma forma de evitar que essa pessoa seja “toda poderosa”, e permitir mais pessoas dentro do processo? Talvez tenha alguma coisa nesse sentido mas eu confesso que eu não sei muito… e vocês?

Gabriel Araújo: Você sabe que eu sou otimista, né? Então vamos lá: eu curto muito esse negócio de open source e me dá gosto de ver o sucesso que o Flutter tem feito e o tanto que tem crescido como linguagem em empresas relevantes; além de ver que é cada vez mais utilizado em um espaço curto de tempo, se a gente for parar para pensar… e isso eu acredito que seja muito em função do fato de o código ser totalmente aberto. Eles tem uma equipe que é muito engajada nesse senso de comunidade, e que é muito ativa em relação a fazer a linguagem ser realmente a melhor que existe para fazer qualquer tipo de desenvolvimento. Esse é o objetivo final deles: eles querem pegar web, mobile e tudo o mais que conseguirem.

Lançaram até um game engine na versão Beta pra quem gosta de brincar com isso, mas eu acredito que quanto mais a gente der valor para essa parte do open source, quanto mais nós que utilizamos bastante começarmos a contribuir mais, acho que isso não tem limite… é um crescimento que vai acabar acontecendo naturalmente. E claro, a gente tem que tomar cuidado, como o Douglas falou, pois já vimos alguns exemplos de coisas perigosas que podem acontecer. Mas cara, a gente usa open source todo dia… então porque não ajudarmos a crescer ainda mais isso, e ajudar a tecnologia ficar cada vez mais relevante na vida das pessoas? Eu acredito muito nisso.

Flávio Lisboa: O open source já faz parte do presente: ele é usado nas mais diversas aplicações, desde um browser open source no celular, até um sistema operacional, ou mesmo algum serviço do governo que é baseado em plataformas open source; hospedamos aplicações na nuvem, que também possui ferramentas open source.. então o open source já está espalhado pelo mundo. E nesse cenário estamos, de Indústria 4.0, de grande automação, o desenvolvimento colaborativo é bastante importante. Afinal, temos sistemas altamente complexos e gigantescos que precisam de pessoas que saibam trabalhar de forma colaborativa. Então acredito que os projetos open source são um caminho muito bom para os profissionais que querem se integrar a esse mundo de desenvolvimento, que é esse mundo de futuro colaborativo.

E nós aqui no Brasil temos até lugares que são especializados em pesquisa sobre isso. Por exemplo, a USP conta com o Centro de Competência em Software Livre (CCSL). Existem vários projetos que são conduzidos por esse centro, que faz parte do IME. No Paraná temos o C3SL, o Centro de Computação Científica e Software Livre, que inclusive também hospeda alguns repositórios de código aberto como o do Debian no Brasil. Então temos comunidades aqui no próprio Brasil em que você pode começar a trabalhar até ter alguma experiência e daí partir para algum outro projeto. O que não falta é oportunidade, tem uma série de repositórios que você pode contribuir nas mais variadas linguagens.

—
Para assistir ao meetup Open Source com Flávio Lisboa, Douglas Iacovelli e Gabriel Araújo, acesse:

Referências:

Quer começar a contribuir com alguns projetos de software de utilização ampla? Conheça os projetos:

LibreOffice: https://pt-br.libreoffice.org/comunidade/participe/
Gimp: https://www.gimp.org/develop/
A Linux Foundation também conta com muitos projetos que precisam de colaboradores, e que você pode acessar em: https://www.linuxfoundation.org/projects/#explore
Lembre-se sempre de buscar tarefas simples para iniciar e interagir com os membros da comunidade. Como isso leva tempo, de acordo com o conhecimento e a experiência de cada um, seja resiliente.