Michael Meeks, um dos desenvolvedores de destaque do OpenOffice.org, e especialmente do ooo-build, repositório que contém uma versão modificada do sistema para incluir diversas alterações de código aberto contribuídas pelas distribuições e pela comunidade mas que não foram (ainda ou em definitivo) aceitas pela Sun para inclusão no OpenOffice "oficial", publicou um manifesto contra a forma como a Sun lida com contribuições da comunidade ao OOo.

Michael, que recebe salário da Novell para se dedicar ao desenvolvimento do OpenOffice, já está acostumado a atribuir à Sun a autoria dos códigos que desenvolve, para que ela aceite incluí-lo no sistema. E ele diz entender a razão da Sun: é que assim, ao mesmo tempo em que o código fica disponível como software livre, ele sabe que a empresa tem condições de relicenciá-lo e distribui-lo também no seu proprietário StarOffice, ou em outros produtos de código fechado à escolha dela. Mas ele reconhece o quanto a Sun já investiu e ainda investe no OpenOffice.

Só que ele vê um problema mais sério quando esta política passa a ter potencial de comprometer a capacidade de o OpenOffice ser bem-sucedido como um projeto desenvolvido no modelo aberto, em especial em casos como a saga de Kohei Yoshida, que ao longo de anos desenvolveu um Solver para o OOo Calc, com o conhecimento e até mesmo em colaboração com a Sun, para ao final ver a empresa decidindo que não iria aceitar integrar o seu Solver, mas sim iria reimplementar toda a solução, porque Kohei não estava disposto a compartilhar a autoria do sistema com a Sun da mesma forma que Michael Meeks faz - ele preferia disponibilizar o módulo sob a licença LGPL, a mesma que a Sun usa para distribuir o OpenOffice a seus usuários.

O relato de Michael Meeks (com esclarecimentos posteriores após a repercussão de uma nota pobremente intitulada no Slashdot) apresenta detalhes e trechos de e-mails públicos sobre a rejeição da inclusão, e comenta sobre a situação do OOo com relação a não estimular a participação de desenvolvedores independentes - embora não seja o único projeto livre a exigir completa atribuição de direitos autorais à entidade mantenedora, ele se diferencia por esta atribuição nem sempre ser usada no interesse do projeto em si, mas sim no interesse da entidade mantenedora.

E é neste ponto que entra o repositório comunitário ooo-build, que já está em operação há 5 anos e é a base das versões do OOo de várias distribuições: ele inclui os módulos e patches que a Sun rejeitou - até mesmo o Solver de Kohei. Não é propriamente um fork, mas sim um derivado, da mesma forma que o Symphony, o RedOffice e o próprio BrOffice. Há uma característica fundamental: todas as alterações são enviadas à Sun para inclusão no OpenOffice "oficial", embora ela não aceite todas elas.

Quem ganha com a manutenção do status atual? Aparentemente não é a Sun, especialmente se o ooo-build começar a avançar muito em funcionalidade em relação ao código oficial. Aparentemente também não é o OpenOffice.org enquanto projeto comunitário, especialmente se a situação começar a tomar mais contornos de fork. Mas o fato de poder haver uma base de código fora dos domínios da empresa mantenedora do projeto é um dos benefícios do modelo de código aberto que não podemos desprezar.

Vamos aguardar a resposta da Sun ou mesmo um posicionamento oficial da comunidade OpenOffice internacional!

Saiba mais (gnome.org).

Leia também: OpenOffice.org community conflict leads to fragmentation, no Ars Technica.