Perché le prime versioni di LibreOffice avevano tanti problemi ?

Quando è nato il progetto, con l’obiettivo di apportare una serie di modifiche sostanziali sia all’organizzazione del processo di sviluppo sia al codice sorgente di LibreOffice, c’erano diverse opzioni: (1) rilasciare immediatamente il software pur sapendo che ci sarebbero state almeno due versioni “problematiche”, (2) aspettare almeno un anno prima di rilasciare la prima versione – a questo punto stabile – di LibreOffice, e (3) evitare di apportare le modifiche.

Siccome la terza opzione non era percorribile, perché il codice sorgente di OOo – dopo dieci anni di immobilismo, di “si è sempre fatto così, perché mai dovremmo cambiare” e di “questo è impossibile” – aveva bisogno di un rinnovamento, e la seconda avrebbe causato un’immediata perdita di credibilità da parte del progetto, perché senza il software sarebbe stato fin troppo facile scagliarsi contro il gruppo dei promotori con ogni tipo di accusa (in realtà, questo è avvenuto ugualmente, perché la realtà è andata – purtroppo – oltre l’immaginazione), è stato facile decidere per la prima opzione.

Le due linee di prodotto LibreOffice 3.3 e LibreOffice 3.4, che sono state quelle disponibili per tutto il 2011, hanno avuto i problemi di instabilità tipici di una fase di transizione da un progetto in cui non si utilizzavano strumenti di automazione – per esempio, la Quality Assurance veniva fatta quasi tutta “a mano”, perché OOo aveva un numero insolitamente elevato di addetti alla QA (circa 40, per circa 60 sviluppatori) che erano ovviamente contrari all’automazione – a uno in cui si puntava a un’automazione spinta, soprattutto della QA.

Per arrivare a un risultato confrontabile a quello di OOo, è stato necessario creare una batteria di “tinderbox” che compilano automaticamente LibreOffice più volte al giorno (in media, ogni 20 commit), seguiti da una batteria di test automatizzati (oggi sono circa 120) che “consegnano” il software al team di QA per la batteria dei test manuali (che sono indispensabili, ma devono arrivare solo dopo che le macchine hanno fatto il loro lavoro).

Grazie a questo lavoro, fondamentale, svolto soprattutto da due volontari – Norbert Thiebaud per i “tinderbox” e Markus Mohrhardt per i “torture test” – la qualità delle release di LibreOffice successive alla 3.5, presentata a gennaio 2012, è migliorata in modo significativo, tanto che tutte le migrazioni da quel momento sono state a LibreOffice e non più a OOo.

Purtroppo, la transizione ha generato in un gruppo di utenti – particolarmente affezionati a OOo, e privi delle conoscenze di sviluppo necessarie per capire cosa stava succedendo nelle retrovie del progetto – un atteggiamento di rifiuto totale nei confronti di LibreOffice, a causa della scarsa qualità del software rispetto a OOo, dovuta – secondo loro – all’incapacità degli sviluppatori (che in molti casi erano gli stessi che venivano osannati quando lavoravano sul codice di OOo, come Michael Stahl ed Eike Rathke).

Questo atteggiamento permane a tre anni di distanza, tanto che c’è qualcuno che continua a definire LibreOffice come “sperimentale” nonostante sia stato preferito a OOo e AOO da organizzazioni come la Gendarmerie Française (250.000 PC), la Comunitat Valenciana (120.000 PC) e la città di Monaco di Baviera (15.000 PC) proprio per la superiore qualità sia del progetto sia del software.

Leave a Reply

Your email address will not be published. Required fields are marked *