Add-ons do Plone: usar o da comunidade ou desenvolver o seu

Dois erros opostos com add-ons

Em um portal Plone de órgão público, use o add-on da comunidade quando ele resolve a necessidade e tem manutenção ativa. Desenvolva o seu quando nada cobre o comportamento de que o órgão precisa, ou quando o candidato está abandonado e o risco de mantê-lo é maior que o de escrever outro. Nos dois casos, alguém precisa ser dono do código.

Add-on do Plone é um módulo que acrescenta uma função ao CMS, como um tipo de conteúdo novo, um formulário com regra própria ou uma ligação com outro sistema.

Este texto é para a equipe técnica do órgão que mantém um portal em Plone e para a integradora que o acompanha.

A decisão costuma dar errado de duas maneiras opostas.

Instalar o que estava à mão

O primeiro erro é instalar o primeiro add-on que parece servir. Funciona no dia da entrega, e ninguém pergunta quem o mantém. Meses depois, o projeto parou, e o portal fica preso a ele. É o caso do módulo pequeno que impede a atualização do portal inteiro.

Escrever o que a comunidade já mantém

O segundo erro é o inverso. Por desconfiança do que é de fora, o órgão manda desenvolver algo que a comunidade já resolve e mantém. Paga-se para escrever, testar e atualizar um código que já existia, e o resultado ainda precisa de dono.

Um exemplo hipotético, só para ilustrar: um órgão precisa de um calendário de eventos. Se existe um módulo mantido, com uso ativo, escrever outro dificilmente se justifica. Agora um segundo caso, também hipotético: o órgão precisa de um fluxo de aprovação que segue uma portaria interna. Dificilmente algum módulo pronto cobre essa regra.

O que une os dois erros é decidir por conveniência. A decisão certa vem de critérios.

Critérios para avaliar um add-on da comunidade

Antes de instalar, avalie o candidato como se avalia qualquer dependência: pelo que acontece com o portal se ele falhar. Os critérios abaixo ajudam a pesar isso.

Quem mantém e com que frequência

Veja quem responde pelo código: uma pessoa, uma organização, uma comunidade. Veja também quando saiu a última publicação e se as questões abertas recebem resposta.

Se falhar: o add-on depende de uma única pessoa, que pode mudar de prioridade, e o órgão fica sem ter a quem recorrer.

Se acompanha a plataforma

Um add-on ativo precisa declarar com quais versões do Plone funciona e ser testado contra as versões atuais. Confira isso na documentação do projeto, e não por impressão.

Se falhar: ele funciona hoje, mas prende o portal à versão em que parou, e a atualização espera por ele.

Se cobre a necessidade, sem sobra

Compare o que o módulo faz com o que o órgão precisa. Função que falta vira adaptação. Função que sobra vira código instalado, exposto e sem uso.

Se falhar: o órgão adapta o add-on e passa a manter uma versão própria dele, sem ter percebido que escolheu isso.

Licença, documentação e testes

A licença precisa permitir o uso e a alteração pelo órgão. A documentação deve explicar instalação e configuração. Os testes automatizados mostram se alguém se preocupa com o que muda a cada publicação.

Se falhar: cada atualização vira uma aposta, e quem herdar o portal terá de descobrir sozinho como o módulo funciona.

Acessibilidade e LGPD do que ele entrega

Verifique, não presuma. Um add-on que gera telas ou formulários entrega também a acessibilidade (eMAG e WCAG) de cada tela. Um que coleta dados pessoais passa a fazer parte do tratamento descrito na LGPD. Nenhum módulo cumpre isso sozinho: é preciso testar o resultado no portal.

Se falhar: o problema aparece na auditoria ou na reclamação de um cidadão, e não na instalação.

Lista de checagem

• Há quem responda pelo código, e a última publicação é recente?
• A documentação diz com quais versões do Plone ele funciona?
• Ele cobre a necessidade sem acrescentar o que o órgão não vai usar?
• A licença permite usar e alterar?
• Há testes e documentação de instalação?
• A acessibilidade e o tratamento de dados pessoais foram verificados no portal?

Se a resposta for não para itens centrais, o candidato é uma aposta fraca, e vale considerar a alternativa.

Quando desenvolver o seu faz sentido

Escrever um add-on é a escolha certa em alguns cenários bem definidos.

Regra específica do órgão

Fluxo de publicação que segue uma norma interna, tipo de conteúdo que reflete um procedimento do órgão, campo exigido por uma resolução. Quando a regra é do órgão, não existe módulo pronto que a cubra, porque ela só existe ali.

Integração com sistema interno

O portal pode precisar mostrar dados de outro sistema, como o de processos, o de ouvidoria ou o de cadastro de servidores. A ligação entre os dois é específica e costuma ser feita por API. Esse trabalho é tratado em integrações de API.

Candidato abandonado

Às vezes o módulo que faz o que o órgão precisa existe, mas parou de ser mantido. Há três saídas, e a escolha depende do estado do código.

• Adaptar: vale quando o módulo é pequeno, a licença permite e o código é legível. O órgão passa a ser o mantenedor, e precisa aceitar isso.
• Trocar: vale quando existe outro módulo ativo que cobre o essencial, e a migração dos dados é viável.
• Reconstruir: vale quando o módulo faz pouco, o código está distante da plataforma ou ninguém o entende. Escrever de novo, só o que o órgão usa, costuma custar menos que carregar um código que ninguém domina.

O Plone é escrito em Python, e é nessa linguagem que o add-on próprio é feito. O importante aqui não é a linguagem, e sim o que vem depois do código pronto.

Add-on próprio também precisa de dono

Add-on próprio custa manutenção da mesma forma que o da comunidade. A diferença é que, no próprio, o órgão é quem mantém. Cinco práticas fazem esse custo caber na rotina.

• Testes automatizados. Mostram se uma atualização quebrou alguma coisa antes de o portal ir para o ar.
• Documentação. O que o módulo faz, como se instala e como se configura, em linguagem que outra pessoa consiga seguir.
• Atualização junto com o Plone. O módulo acompanha a plataforma a cada atualização, e não só quando algo quebra. Isso faz parte da sustentação do portal.
• Registro de decisão. Por que o módulo existe, o que foi considerado e por que o pronto não serviu. Daqui a alguns anos, essa é a primeira pergunta de quem herdar o código.
• Transferência de conhecimento. Quando o fornecedor sai, o conhecimento não pode sair junto. O que isso envolve está em transferência de conhecimento.

A pergunta que fecha a decisão é simples: quando o fornecedor sair, quem mantém este código? Se a resposta é "ninguém" ou "não sabemos", o add-on é uma dívida, mesmo funcionando.

Para entender a plataforma por trás dos módulos, veja o que é Plone.

Se nenhum módulo conhecido cobre a sua necessidade, ou se um add-on abandonado trava o portal, comece avaliando o candidato com os critérios acima e decidindo entre adaptar, trocar ou reconstruir. Quando o comportamento de que o órgão precisa não existe pronto, a frente de add-ons em Python de Plone para governo trata de desenvolvê-lo.