Open Source como base

Há uma visão viciada no mercado — principalmente no Brasil — de que open source é apenas um produto de consumo. A grande maioria dos empreendimentos atuais vai consumir diversos projetos gratuitos, mas poucos vão produzir código aberto.


Quando eu vim procurar uma oportunidade na Bocoup, uma das coisas que mais me chamava atenção era poder dedicar 25% do tempo de trabalho com projetos open source. Garanto que isso é tão bom quanto me parecia naquela época.

Pode ser qualquer coisa open source, eu escolho. Ninguém me diz o que tenho que fazer e isso não precisa se vincular a um produto da empresa. Eu posso usar esse tempo escrevendo código, fazendo triagem de bugs em projetos, organizar um evento para uma comunidade de desenvolvimento de software, eu posso até escrever documentação de um código. Não há um sistema de controle, as pessoas automaticamente vão encontrar algo de seu interesse e vão se sentir bem porque sabem que estão sendo pagas para fazer algo por vontade própria.

A outra parte incrível desses 25% de tempo dedicado, é que ele não precisa ser utilizado em um período específico. O sugerido é que ela seja utilizado ao decorrer do dia ou da semana. Se você precisar se focar mais em algum projeto durante a semana, nada é impossível de ser ajustado.

Hoje, quando eu falo sobre isso com alguns colegas, muitos me respondem que a empresa ainda é frágil, nova demais pra isso, ou que ainda precisa se ajustar primeiro para um dia permitir isso. Eles apresentam esse último argumento como uma variável, mas é uma constante. Eles também não sabem o quanto seria o retorno do tempo investido.

Quando você adota a prática do tempo livre para Open Source, você coloca a sua equipe em um outro padrão.

Vamos ao exemplo de algumas empresas grandes. Google, Microsoft e IBM. Justamente por serem grandes, essas empresas conseguem manter times de pesquisa e evangelização, entre vários outros relacionadas a projetos abertos que elas mantém. Qual é o resultado disso? Os desenvolvedores naturalmente se interessam e vêm participar desses projetos.

Ainda não percebeu o quanto esses projetos atraem novos desenvolvedores? Veja como tem pessoas por aí trazendo o AngularJS como parte do currículo. O AngularJS é um projeto do Google para criar um framework que seja de fácil entrada por novos desenvolvedores e também designers. Eu já vi, pelo menos, três artigos no Brasil de gente usando o AngularJS como um exemplo para alguém que quer começar a contribuir com open source.

O que isso muda para a empresa? A Google estabelece contato com os novos desenvolvedores, apresenta a eles bons padrões de desenvolvimento, usa as ferramentas populares como o Github, e as pessoas sonham mais e mais com o dia que vão poder trabalhar lá.

Se isso ainda não convenceu, veja — em termos de objetivo para a carreira — quantas pessoas querem trabalhar no Google e quantas querem trabalhar na Apple. Perceba o quanto dessas pessoas podem até consumir mais produtos Apple, ou melhor, quantas querem usar um MacBook ou até um iPhone. A empresa mais visada para consumo não é sempre a mesma empresa mais visada para carreira.

Como isso se relaciona às empresas pequenas?

Um amigo meu costumava repetir uma frase: "para eu vestir a camisa da empresa, a empresa tem que vestir a minha camisa primeiro". Não há nada mais correto que isso, e não há verdade pior que perceber inúmeras propostas de emprego onde a empresa não se preocupa em se apresentar.

Existem muitos lugares bons para se trabalhar no Brasil, mas a empresa vestir a camisa do funcionário é o tipo de investimento que falta em alguns destes lugares, para que tornem mais atraentes que os outros bons lugares. Coloque na agenda dos seus desenvolvedores esses 25% de dedicação a projetos abertos e você vai ganhar o mesmo efeito que o Google faz, sem você precisar da estrutura de um time de pesquisa ou evangelização.

Isso me lembra o quanto eu vejo de empresas e até colegas argumentando como é difícil achar profissionais. Talvez esse seria um ótimo investimento para fazer com que ótimos profissionais encontrem essas empresas. Sei que um dos motivos que as pessoas que trabalham comigo ou que querem vir trabalhar é justamente esse tempo. Nós vestimos a camisa, é claro que não é o único motivo, mas é um dos que mais chamam a nossa atenção.

Só para atrair profissionais não seria um investimento caro?

Poderia ser, mas esse não é o único retorno desse tempo dedicado. Há outros retornos que vão mais além. Um deles é a pesquisa.

Se você trabalha com JavaScript já deve ter ouvido falar do Grunt. Ele foi criado aqui na Bocoup e surgiu através desse tempo dedicado para Open Source. Ele mudou muita coisa na vida de muitos desenvolvedores, e não foi diferente por aqui. Com esse tempo não focado em uma tarefa específica de um projeto fechado, foi permitido que um outro projeto surgisse. Com esse novo projeto foi possível reduzir drasticamente o tempo de pequenas operações rotineiras que tomavam o tempo pela quantidade de vezes executadas e que hoje fazem parte das rotinas de verificação automatizadas de qualidade.

Não é só um projeto como o Grunt que surge. Eu mesmo dedico boa parte do meu tempo Open Source com o QUnit, que é um framework de testes. Não só a empresa ganha um profissional que está estudando constantemente sobre esse assunto, mas que sabe toda a API dessa ferramenta, e se alguma parte dessa ferramenta precisa melhorar ou ser corrigida, eu sei estimar muito bem o que pode ser feito e quando pode ser feito. Já houve vezes em que colegas no Brasil vieram tirar uma dúvida sobre o assunto e não precisaram perder tempo pesquisando o que estava errado em seus testes.

Com um time diversificado, nós sempre temos alguém para tirar alguma dúvida sobre um projeto que nunca vimos antes. As vezes esse tira dúvida se torna uma mini aula.

Às vezes ninguém conhece um projeto e aí entra a hora do poleiro.

Chamado aqui de Perch time, eu quis traduzir esse nome para dar a impressão que o pessoal tem aqui. O nome é estranho, mas a prática é maravilhosa.

Eu trabalho no time de consultoria, isso significa que normalmente estou trabalhando em projetos externos, para outras empresas, clientes. A Bocoup também reserva parte do nosso tempo — sem prejuízo ao tempo de Open Source — para nos dedicarmos a projetos "poleiro".

Nesses projetos poleiro, passamos um tempo com um projeto interno. Não somos obrigados a passar em qualquer projeto, podemos escolher, eles podem ser open source ou não, mas uma coisa é certa: o objetivo é aprender algo.

Eu aprendi a usar EmberJS, Ember-cli, Ember-data, etc, trabalhando em mais de um projeto desses por cerca de dois meses inteiros. Eu agora tenho confiança plena de trabalhar em um projeto de consultoria que envolva essas tecnologias. Inclusive aprendi sobre algumas outras ferramentas mais, como o Ansible e o Vagrant, e até algumas coisas que poderiam ser melhoradas no QUnit que voltam como retorno ao EmberJS, como o suporte a Promises e uma remodelagem nos testes assíncronos.

Se você acha tudo isso muito bom, ainda tem mais.

Existe uma coisa que dificilmente se aprende com uma equipe pequena, mas facilmente em projetos open source. Processo de desenvolvimento.

Assim como você aprende TDD perfeitamente em sessões de Coding Dojo, trabalhar em projetos abertos faz você aprender vários processos. Um dos maiores deles é no próprio git. Antes de começar a me aventurar pelo Github, eu limitava meu uso do git a fazer commit e sincronizar meu repositório com pull e push. Não tinha na minha cabeça o conceito correto de branches, fazia algumas coisas bobas.

Quando você trabalha em projetos abertos você passa por um sistema de revisão que não tem como foco a entrega, mas sim a qualidade. Alguém vai olhar seus commits e seu código e vai analisar cada detalhe, você está sujeito a qualquer típo de crítica. Nenhuma delas é pessoal, na maioria das vezes não existe uma intenção de ofender.

A outra parte é o desapego ao código. Eu já tive que jogar fora alguns Pull Requests enormes que tinha feito, porque eles não expressavam bem o que eu tentava fazer, ou porque fiz da forma errada. Alguns outros passaram por mais de uma semana de críticas em cima do código. Tive de corrigir e mudar muita coisa, na maioria das vezes eu ouvi ótimos argumentos que prevaleceram sobre minha falta de argumentos, às vezes meus argumentos convenceram do contrário. Eles só precisavam ser consistentes.

Aprendi ali o que não aprenderia em uma outra equipe fechada, eu tinha basicamente milhares de pessoas que se dedicavam a revisar meu código. Pequenos vícios eram eliminados.

Eu poderia falar mais disso como o período no qual me tornei experiente em desenvolvimento, mas sei que ainda vem muita coisa nova pela frente e ainda sei quase nada. Mesmo assim, sei muito bem de uma coisa: vista a camisa dos seus profissionais, deixe-os pesquisarem e aproveitarem esse tempo de aprendizado gratuito promovido por uma comunidade focada em qualidade.

Sua equipe pode ser de apenas três pessoas, mas o potencial dela pode ser equivalente à quantidade de pessoas presentes nos mesmos projetos que elas participam.


Gostou do texto? Então clique no botão Recommend, logo abaixo.
Fazendo isso, você ajuda esta história a ser encontrada por mais pessoas.

Não tem conta no Medium? Que tal fazer login clicando aqui? Leva um segundo. Após fazer isso, você pode seguir a publicação oficial do Medium Brasil e receber todos os dias nossas atualizações. Clique e siga o Medium Brasil. ☺

Siga o Medium Brasil | TwitterFacebookRSSCanal oficial