Tom's Hardware Italia Tom's Hardware
Software

Open Office a un passo dalla chiusura, mancano sviluppatori

Il progetto OpenOffice rischia davvero di chiudere i battenti per carenza di sviluppatori. Il primo settembre Dennis Hamilton, vice presidente di Apache OpenOffice, ha pubblicato una lettera online che suona come un allarme. In "What would OpenOffice retirement involve?" ha spiegato come 6 volontari non siano più sufficienti per far fronte al mare di fix di sicurezza di cui avrebbe bisogno il pacchetto di produttività personale un tempo più famoso del settore open.

open office
Un open office vuoto

"Il ritiro del progetto è una sera possibilità", sostiene Hamilton. D'altronde i fatti sono conosciuti. Molti sviluppatori hanno tradito OpenOffice con LibreOffice alla fine del 2010. Dalla prima edizione di gennaio 2011 si sono susseguiti molti aggiornamenti, mentre OpenOffice è rimasto praticamente al palo (la 4.1.2 risale a ottobre 2015).

La criticità più eclatante si è manifestata lo scorso luglio quando si è scoperta una falla che avrebbe potuto consentire attacchi denial-of-service e l'esecuzione arbitraria di codice. Ad agosto è stato realizzato un fix ma la tempistica ha confermato i problemi di intervento. In verità del rischio (proof of concept) si sapeva già ai tempi della versione 4.1.2 ma il confronto interno non è stato risolutivo.

open office
Open Office 4

Ecco spiegato il motivo per cui il board di Apache OpenOffice ha chiesto al comitato del progetto Open Office "di dar conto sulla sua incapacità a fornire un rimedio". L'ideale sarebbero aggiornamenti mensili, non trimestrali come avviene oggi.

Se le cose dovessero volgere al peggio il codice sorgente rimarrebbe disponibile, ma non vi sarebbe alcun obbligo per gli aggiornamenti, le mailing list sarebbero chiuse e tutti gli account social nonché il blog scomparirebbero. Apache manterrebbe solo una mail per le richieste d'uso.

Una delle proposte di risoluzione è giunta da uno sviluppatore che ha co-fondato Apache Software Foundation: Jim Jagielski suggerisce di trasformare il tutto in un framework o libreria per le implementazioni degli utenti. Insomma, non più un progetto a senso unico.