BOAS PRÁTICAS

As Tecnologias de Informação estão presentes em todos os sectores. Constituem ferramentas indispensáveis com poder estratégico muito alto, no entanto também têm os seus riscos e por isso devem ser cumpridos alguns princípios de boas práticas.

Boas práticas podem ser definidas como um grupo de procedimentos que contribuem para a otimização da eficiência (GARTNER, 2019) ou como “método de trabalho que é oficialmente aceite como sendo o melhor para utilizar num negócio ou indústria específica“ (CAMBRIDGE, 2019).

Desta forma, sugerimos algumas Best Practices no manuseamento de softwares Open Source:

Estabelecer uma política de utilização / código de conduta
Deve existir uma política de utilização para evitar problemas futuros, designadamente como forma de gerir expectativas. As circunstâncias do desenvolvido do código não são de conhecimento público, os utilizadores podem erradamente assumir que o programador está unicamente dedicado a esse projeto (e pode já estar focado noutro diferente) ou que é remunerado para para o realizar (e pode não ser assim), entre outros. Por isso deve-se informar à priori qual a forma de revisão/aceitação dos contributos, tipo de contributo (deve-se informar quando só se espera colaboração para uma parte do código, se aplicável), o tempo de resposta expectável e informar qual o tempo que o criador dedica ao projeto semanalmente (Open Source Guides, 2019).

Documentar os processos
A documentação dos processos permite não só explicar a linha de pensamento do programador, como permite à comunidade participar e colaborar mais facilmente. Essa documentação deve manter-se atualizada, ao excluir a parte desatualizada promove-se clareza e estimula-se novas atualizações. Os objetivos do projeto podem constar no README, ou eventualmente num ficheiro VISION, quando se justificar (Open Source Guides, 2019).

Fazer atualizações constantes
Quando são descobertas fragilidades no código, é necessário que as atualizações que corrigem esses erros sejam realizadas rapidamente. A rápida correção vai depender da visibilidade de todos os componentes do código (WAINSTEIN, 2018) mas não essenciais para garantir o sucesso do código.

Priorizar a qualidade
Os programadores podem ter tendência a utilizar componentes com os quais estão mais familiarizados. No entanto, devem priorizar a qualidade dos componentes. Este é um dos maiores desafios neste domínio. O grau de confidencialidade e estabilidade do projeto passa muitas vezes pela análise da quantidade e gravidade dos bugs descobertos. Outro indicador, é o estado da comunidade, em relação ao seu grau de atividade ou e quantidade de programadores que estão envolvidos no projetos (WAINSTEIN, 2018).

Recorrer a várias ferramentas tecnológicas
As ferramentas de controlo permitem monitorizar as vulnerabilidades de segurança, ao possibilitar o rastreamento da origem dessa potencial falha e consequente concerto. O Jenkins é um exemplo desse tipo de ferramenta. Estas ferramentas são ainda úteis para garantir que a licença de Open Source está a ser cumprida (WAINSTEIN, 2018).
Um gerenciador de repositório binário pode ser outra ferramenta importante, por contribuir para a gestão das componentes do código aberto. Este permite armazenar cópias locais de componentes do código, que por sua vez permite aceder ao código mesmo quando se verifica algum de indisponibilidade dos repositórios externos. E ainda, possibilita melhorar a visibilidade e controlar o código (por exemplo no sentido de garantir que não são feitas alterações que condicionem o projeto em questão) (WAINSTEIN, 2018).

Participar na comunidade
Este é um dos princípios basilares da utilização do código aberto. O constante contributo é o que permite ao código crescer, solidificando-se. A participação na comunidade tanto pode ser no sentido de simplificar o seu próprio trabalho como contribuir para facilitar o trabalho de outros (que se pode traduzir em melhorias no seu projeto). Por isso, e sempre que se descobre algum bug, deve-se primeiro verificar se consta na lista de problemas encontrados, enviar relatório a informar a comunidade e por último enviar a correção para a comunidade (WAINSTEIN, 2018). As comunicações devem sempre ser públicas, caso exista alguma tentativa de esclarecimento privado, esse deve ser remetido para a comunidade, as dúvida/contributos de um podem ser iguais a vários (Open Source Guides, 2019).
A liderança da comunidade não tem de ser fixa ou exclusiva. No caso de existir alguém se destaque positivamente pela eficácia e frequência de colaboração, pode ser convidado a assumir mais responsabilidades. Ou se por algum motivo o líder deixar de ter o tempo necessário para dedicar ao projeto deve pedir que alguém assuma essa responsabilidade (Open Source Guides, 2019).

Bifurcações cautelosas
Uma das grandes vantagens do Open Source é existir permissão para obter cópia do código e modificá-lo de forma independente. Apesar das bifurcações do código permitirem acompanhar as alterações de componentes do código-fonte, idealmente só devem ser realizadas quando se espera que o projeto inicial não será mais atualizado (WAINSTEIN, 2018).