Uma das características mais importantes de um projeto colaborativo como o BrOffice.org é a possibilidade que o usuário tem de contribuir com melhorias para o código dos aplicativos. Objetivamente, essas melhorias podem ser traduzidas como registros de problemas, sugestões de modificação de funções existentes ou implementação de novas funcionalidades.

Em outubro de 2009, dentro das atividades do projeto de consultoria de suporte ao BrOffice.org para o Tribunal de Contas do Estado de Mato Grosso, um usuário descobriu um problema relacionado à definição das margens através da visualização da impressão no Calc.

Ao abrir um arquivo e modificar as margens na visualização de impressão, sem fazer qualquer outra alteração, o Calc não habilitava o botão de salvamento. Ou seja, erroneamente, o Calc não interpretava a alteração nas margens como uma modificação de conteúdo no arquivo quando feita através da visualização de página. No entanto, ao fazer o mesmo procedimento de modificação de margens através do menu Formatar > Página, guia Página, o comportamento é normal e o botão de salvamento é habilitado.

Pois bem, o registro do problema foi feito por mim no sistema de registro de melhorias do projeto OpenOffice.org, o Issuezilla, em 20 de outubro de 2009. O registro pode ser verificado no endereço:

http://qa.openoffice.org/issues/show_bug.cgi?id=106108

O problema foi registrado na versão 3.2.0 sobre Windows XP, o sistema operacional predominante no TCE/MT. Apesar de ser um registro muito simples de ser verificado, não houve resposta imediata, o que fez com que eu enviasse uma nova mensagem no dia 3 de agosto de 2010 solicitando informações sobre o registro.

Ao mesmo tempo em que aguardava alguma resposta, no dia 28 de setembro de 2010 foi criada a The Document Foundation, contando com o apoio e participação do projeto BrOffice.org desde o seu início. As razões da criação da The Document Foundation são claras e já foram detalhadas inúmeras vezes, no entanto, vale a pena lembrar que uma das suas principais justificativas foi a de melhorar o processo de desenvolvimento dos aplicativos a partir das demandas dos usuários.

No dia 29 de outubro de 2010, fiz o registro do mesmo problema no repositório de registros do LibreOffice, disponível dentro da estrutura do projeto FreeDesktop.org. O registro pode ser lido abaixo:

https://bugs.freedesktop.org/show_bug.cgi?id=31219

Apesar de estar marcado como resolvido em ambos os aplicativos, a correção do LibreOffice levou apenas onze dias para ser confirmada e oito para ser resolvida. No projeto OpenOffice.org, o tempo até a confirmação do problema foi de mais de 1 ano e a solução do problema somente após 45 dias.

Outra diferença significativa é o fato de que a correção será liberada na versão 3.3.0 do LibreOffice, enquanto que, no OpenOffice.org, o problema só será corrigido na versão 3.4.

É difícil afirmar se uma solução será melhor que a outra.

Tecnicamente, o processo de resolução de problemas do projeto LibreOffice confirma ser menos burocratizado do que no projeto OpenOffice.org. Uma outra abordagem poderia levar a pensar que a justificativa da resolução mais lenta no OpenOffice.org poderia ser devido à gestão da qualidade de código. Essa é uma afirmação que poderia cair melhor num comparativo entre o OpenOffice.org e o antigo Go-OO, no entanto, ao falarmos do LibreOffice devemos considerar que grande parte da antiga comunidade OpenOffice.org agora pertence ao novo projeto. Além disso, um controle mais apurado não justificaria mais de 1 ano sem qualquer informação sobre a resolução ou não do problema.

Estrategicamente, é a confirmação de que, no futuro, as duas aplicações tendem a se distanciar em relação as suas soluções tecnológicas. Nesse sentido, o avanço do LibreOffice, no qual serão baseadas as versões futuras do BrOffice.org, é inegável. Além, é claro, de uma saudável provocação ao avanço do projeto OpenOffice.org.