Iniciativas que podem ser adotadas para aumentar as chances de seu código tenha uma boa adoção na comunidade
Não importa quão bom seja seu código. Despejá-lo no GitHub não é a melhor forma de fazer um código aberto de sucesso. Se você está procurando maneiras de garantir que seu projeto de código aberto tenha a melhor chance possível de ser bem sucedido, seria difícil encontrar algo mais essencial do que acertar a documentação.
Em sua coluna para o TechRepublic, o colunista Matt Asay, ex-executivo experiente de grandes empresas de software, explicou que embora nunca seja uma boa prática apenas “torcer pelo melhor” ao colocar seu código em uma biblioteca, também é difícil prever exatamente como o código será usado.
Segundo ele, a melhor coisa que uma pessoa ou organização que deseja abrir o código-fonte pode fazer, é simplesmente torná-lo utilizável para possíveis adotantes.
Asay conta que, em 2006, participou de uma conversa mediada por Tim O’Reilly no briefing executivo OSCON, onde conversaram sobre as contribuições do Google e do Yahoo para o código aberto.
Ambas as empresas foram pioneiras nas principais tecnologias de código aberto. Na ocasião, como conta Asay, as duas empresas afirmaram: “ninguém entenderia nosso código ou seria capaz de usá-lo – é muito específico para uma grande empresa da Web”.
Ainda assim, está claro para o colunista que muitas inovações se tornaram populares com projetos de código aberto, como Apache Hadoop (Yahoo), Kubernetes (Google) entre outras. No entanto, não é porque é um código aberto que necessariamente terá sucesso.
Asay conta que, há muitos anos, a Novell abriu o NetMail como o projeto Hula. O NetMail era um produto confiável para webmail, mas como um projeto de código aberto, ele fracassou e acabou morrendo (como Bongo). A Salt Stack, por outro lado, abriu seu código e logo descobriu megaempresas o usando, exemplifica.
Entretanto, ao lançar um código aberto você deixa de ter controle de como ele será usado e se de fato será usado. Como exemplo, ele cita a campanha da senadora americana Elizabeth Warren, que abriu a sua tecnologia de campanha na esperança de que outros candidatos democratas e de causas progressistas usem suas ideias e códigos livres. Porém, nada impede que os republicanos usem da tecnologia em benefício próprio, exemplifica.
“Não por falta de afinidade com Elizabeth Warren, seus ideais ou mesmo sua tecnologia de campanha. Mas talvez não seja adequado para campanhas de menor escala (cidade, estado etc.), ou pode ser mais fácil criar do zero. Existem boas razões centradas na tecnologia para não usar a Spoke, sua plataforma de mensagens ponto a ponto, bem como o Pollaris, sua ferramenta de pesquisa de locais de votação”, diz o colunista.
Inserir um código no GitHub não é útil, não importa quão bom seja o código, relembra Asay. Ele relembra os princípios que detalhou em 2005 e que realmente não mudaram: boa documentação, use um acessível (e licença), tenha uma estrutura modular, etc. Esse é o bloqueio e abordagem essencial do código aberto. Isso não significa que é fácil, ressalta.
Em uma pesquisa do SlashData de 2019 com mais de 15.000 desenvolvedores, Asay conta, os participantes foram questionados sobre o que era mais importante para eles.
Com 62%, a documentação foi a coisa mais relevante citada pelos entrevistados, seguida de tutoriais e ferramentas. “Isso é ótimo, exceto que uma pesquisa do GitHub de 2017 com desenvolvedores de código aberto descobriu que 93% deles odiavam a documentação que estavam usando”.
“Se você está procurando maneiras de garantir que seu projeto de código aberto tenha a melhor chance possível de sucesso, seria difícil encontrar algo mais essencial do que acertar a documentação”.
