L' Open Source nella PA: scontro di pisquani.

Nel "salotto buono" e' ricorrente il tema del software Open Source nella pubblica amministrazione, e devo dire che le discussioni - interminabili - partono sempre da due errori di fatto, ovvero da due false assunzioni. La prima e' che una grande infrastruttura sia un insieme di PC come quello domestico, e la seconda e' che il costo di un software sia il costo di licenza. Andiamo piu' nel dettaglio. Infine, c'e' la vexata quaestio: ma GNu/Linux e' meglio?

Prendiamo il primo dei due punti: quanto pesa  l'infrastruttura.

Sicuramente se avete un PC di casa avrete installato un singolo sistema operativo, un singolo pacchetto Office (o due), e siete praticamente a posto. In questo caso comunicare con gli altri si risolve nel problema del "formato dei file da inviare e ricevere", o poco piu'. In questo senso, quindi il vostro CoO , (Cost of Ownership) si riduce semplicemente alla licenza del software.

Se ragionate cosi', vi appare chiara una cosa: che a fronte di piccole scocciature riguardanti il formato dei file quando li trasmettete, risparmiare qualche centinaio di euro di software su un PC che ne costa 1000 ha un senso. Esce la nuova versione? Beh, cliccate sull' icona dell'"update manager" di Ubuntu , aggiornate e siete a posto.

Adesso supponete di averne  3000 di computer. Sparsi in giro per una regione/provincia. E non potete rischiare che alcuni utenti dicano "aggiorna" e alcuni no. E non potete andare in giro a distribuire a mano , o ad eseguire a mano l'installazione. O meglio, potete: ma quelle ore per le quali pagate il personale diventano CoO, il costo che ha tenere in piedi l'infrastruttura.

Adesso supponete che Microsoft vi offra un sistema, connesso al dominio, per il quale un amministratore centrale fa click , e un dato software si aggiorna su TUTTI i computer. Mica male, eh? Avete risparmiato un sacco di tempo - che vi sarebbe costato - per girare ovunque e - almeno - fare click sull'icona del vostro Ubuntu/Fedora/Whatever.

Ora, esistono sistemi simili per Linux? Certo. Ma per metterli in piedi su 3000 client vi serve consulenza, vi serve lavoro, vi servono spesso licenze, perche' molti di questi sono sistemi proprietari. Ed il vostro CoO cresce.

Poi avete il problema di configurazione. Supponete di dover riconfigurare , che so io, tutti i client di posta elettronica. Microsoft vi offre una soluzione di istribuzione del software che comprende anche la ridistribuzione delle configurazioni. Il guaio viene quando provate su Linux: esistono sicuramente soluzioni simili, basate piu' o meno su OSS, ma quando andate ad implementarle su 3000 computer, scoprite che vi serve gente qualificata, tempo, altra infrastruttura e spesso altro software proprietario.

Alla fine, quindi, se usate infrastrutture grandi, il CoO si compone di diversi strati di costi, che non sono SOLO i costi di licenza, ma i costi Opex dell'infrastruttura. Che comprendono la manutenzione dell'hardware e il supporto (le case supportano l'hardware su OGNI os?), la distribuzione di patch e nuovo software in maniera programmata e controllata, la gestione della configurazione di ogni singolo pezzo. E siccome sul piano dell'infrastruttura "grande" questi sono i costi MAGGIORI, possono divorare il risparmio legato alle licenze con estrema facilita'.

Detto questo, andiamo al punto essenziale: ma col software Opensource, ove di solito si intende GNU/Linux, puoi fare le stesse cose ? OpenOffice e' una valida alternativa? Questo si riferisce normalmente ad un ipotetico impiegato che debba usare il desktop.

Non potete dire "Ma Openoffice/LibreOffice fa meno cose di Office" e rispondere "ma il costo e' minore", sempre per il motivo di cui sopra: il CoO in grandi installzioni dipende minimamente dal costo di licenza.

Nel caso di Open/LibreOffice la discussione diventa sempre la stessa, e si svolge sul binario del delirio: da un lato Microsoft Office /Exchange e  tutto quanto, e dall'altra parte "che cosa possiamo inventare per fare circa le stesse cose, ma non saremo mai a quel punto".

Questo atteggiamento, che purtroppo e' stato usato come paradigma ANCHE per sviluppare i prodotti, ha prodotto di per se' prodotti scadenti.

Ora, e' assolutamente chiaro che ad OpenOffice/LibreOffice manchi il titanico supporto che deriva dal concetto di OLE. Non c'e' pezza, e le speranze di inseguire Office su questo piano sono semplicemente ridicole.

E' altrettanto chiaro che OpenOffice/LibreOffice manchi di tutte le librerie di template, macro e script e utilities che ci sono per Office.

Adesso i talebani dell' OSS mi diranno minchiate tipo "ma sono funzioni avanzate che non usa nessuno", "ma sono feature specialistiche che chiunque puo' risolvere con un pochino di Verilog, un FPGA, un bench test e una fonderia di silicio", ma il punto non e' questo. Il punto e' che anche dopo aver fatto tutto questo, AL MASSIMO OTTERRESTE LA STESSA COSA.


Insomma, ci sono relle ragioni oggettive nel fatto che il desktop Linux (escluso Android) non decolla?

Io credo di si. E credo le ragioni siano riassumibili cosi':

Il desktop Linux non decolla perche' NON E' DISEGNATO per Linux. E' disegnato per girare su Linux, ma non e' disegnato per avere linux come PATRIMONIO sottostante.

Che cosa intendo?

Prendiamo di per se' un sistema che agisca da calendario. La soluzione seguita da Evolution e' di piazzare un nuovo servizio che gira come demone. Geniale.

Se non fosse che avete gia' l'ottimo, robusto, Cron che gira in background. Perche' scrivere un altro demone? Lo stesso frontend grafico poteva interagire con cron. E potevate realizzare un server di calendari remoto, semplicemente installando Linux, Cron, e SSH per interagire con Cron.

Pensiamo a che senso abbia scrivere un'applicativo desktop che fa da desktop remoto er Gnome. Per altre macchine linux. Avrebbe senso. Si, se non ci fosse X Windows. E Xnest. E se X Windows non fosse gia' un client grafico. Volete dargli un'interfaccia carina? Fatelo. Ma perche' reinventare la ruota con VNC?

E non e' strano: quando masterizzate su Linux, il vostro frontend grafico vi fa decidere cosa volete, ma poi invoca un comando unix , testale, a riga di comando. Un comando piccolo, testato, robusto.

Prendiamo come esempio proprio il famigerato OpenOffice/LibreOffice Writer. Confrontato con Word di Microsoft, troverete un sacco di mancanze. Ma pochissime cose che Writer fa e Word no.

Adesso prendiamo questo: http://www.lyx.org

Si tratta di un "mero" frontend a LaTeX , un sistema mostruoso per la formattazione e l'impaginazione di testi , normalmente in uso per gli scritti scientifici.

Chiamiamo "approccio Lyx" un approccio che si proponga di scrivere dei frontend grafici usabili a dei framework testuali esistenti, testati, stabili, potenti.

Se adesso confrontiamo Lyx a Word, scopriamo che gli mancano un sacco di cose per essere Word.

Ma se facciamo il confronto tra Word e Lxy, scopriamo che anche a Word mancano alcune cose per essere Lyx: nemmeno se fate ogni fatica di Sisifo, potrete convincere Word a creare un documento dalle qualita' tipografiche permesse da LaTeX. non ci provate nemmeno, e' inutile: LaTeX vi stampera' un documento immensamente migliore, piu' bello da leggere, piu' pulito, piu' ordinato, meglio impaginato, sotto ogni punto di vista. Con meno tempo da dedicare all'impaginazione.

z LaTeX ha questa feature, cioe' di scrivervi documenti semplicemente perfetti sul piano editoriale, e ce l'ha come paradigma. Sin dall'inizio: otterrete esattamente quello CHE AVETE IN MENTE. Potete impazzire con Word quanto volete, e l'ultimo arrivato che usi LaTeX e una discreta pratica ( o Lyx)  vi stampa un documento gia' pronto per la tipografia. Senza alcuno sforzo per l'impaginazione, o quasi. Sul piano della qualita' editoriale finale, Microsoft office non gioca questa partita. Ma neanche lo stesso campionato. E nemmeno lo stesso sport.

Allora, adesso veniamo al punto: chi ha ideato Open/Libre Office Writer e' partito dalla convinzione che, nella migliore delle ipotesi, potesse ottenere un prodotto uguale, o - piu' verosimilimente - una versione mutilata.

Ma se avesse detto "questa e' la Linux Way", avrebbe cestinato Open/Libreoffice Writer, a avrebbe incluso e sviluppato un frontend per LaTeX analogo a Lyx. In quel caso, sarebbe COMUNQUE mancato il supporto OLE (e quel che ne deriva) ma in compenso si sarebbe potuto scrivere "Quando poi stampiamo i documenti , MS ce lo puppa". Perche' la qualita' dei documenti di LaTeX e' su una galassia diversa, end of story. Non c'e' partita.

Facendo questo, avreste DAVVERO un'alternativa, ovvero un prodotto DIVERSO che non e' UGUALE (appunto, e' diverso) ma ve la giocate sul piano dei pro/cons. Da un lato Windows ha OLE, voi rispondete con un backend come LaTeX. Allora risparmiate piu' tempo col copia/incolla o con l'impaginazione? Eh, bello scontro, discutiamone.

Quindi, siccome NON si poteva rincorrere Microsoft Office su alcuni punti - ove e' irraggiungibile - la soluzione corretta era di avere alcuni punti ove Open/LibreOffice fosse irraggiungibile. LaTeX era uno di questi. 

Prendiamo l'altro mostro sacro:  Excel.

Per chi ha visto "nascere" quel concetto, tipo Lotus123 per MSDOS, si sa benissimo come siano nati quei prodotti. La necessita' di un oggetto che sapesse fare qualche conticino, e scriverlo su una tabella e fare grafici.

Ora,  se inseguiamo Excel su questa strada, ovviamente ci straccia. MA se vado a cercare prodotti capaci  di fare conticini, generare tabelle e fare grafici, mi trovero' con prodotti pre-esistenti su unix e linux, da gnuplot a R, SciLab,  octave. Ora, volendo creare qualcosa di simile a Excel, sarebbe stato meglio RI-usare l'esistente, e scrivere un frontend Qt/Gnome " fatto a tabella" un frontend per qualcosa come Octave,R,SciLab,Maxima. Roba robusta, testata, efficace, complessa, enormemente POTENTE.

E non dico un frontend per UNO di questi. Dico un frontend con l'aspetto di Excel ma la possibilita' di scegliere, tra le formule, a quale backend mandarle: bc, octave, whatever.  Un backend che giri in locale o meno.

A quel punto Microsoft poteva dire "ehi, ma io ho OLE", e la risposta sarebbe stata "si, ma quando io inizio a macinare numeri con R, una macro statistica di Excel me lo puppa": e avreste avuto PERFETTAMENTE ragione. E vi sarebbe costato quanto costruire un frontend grafico ed impacchettarlo insieme a Octave, R, SciLab e Maxima.

Invece, fare lo stesso di Scilab usando Excel non e' semplice , cosi' su due piedi. Anche se siete bravini con le macro.

E mettendo Scilab/R/Octave/Quelchevipare su un server remoto (opzionale e configurabile), si poteva anche tenere basso il costo di upgrade.

In quel modo avreste avuto sicuramente un prodotto diverso, inferiore ad Excel per certi versi, SUPERIORE - e non di poco! - in altri. E allora c'era la battaglia tra pro/cons.

Perche' a quel punto il rapporto costi/benefici poteva essere alzato: non avete gli stessi "benefici" di word, ma ne avete molti altri. Ad alcuni serviranno, ad altri no. 

Lo stesso potevasi dire di ogni , dico ogni cosa, per ognuno dei programmi che compongono il "desktop linux", dai pacchetti Office ai PIM.

Quando vedo che non c'e' qualcosa come Access mi cascano le braccia. Cioe', come utenti potete tranquillamente far partire un'istanza di mysql/MariaDB, per non parlare di postgres e tutti gli altri DBMS , sino a hadoop e Cassandra, a patto che stia su una porta alta, abbia i file di configurazione nella vostra home folder e i dati nella vostra home. Dunque, si tratta di scrivere un frontend grafico, che arriva insieme ad un Mysql/Mariadb/Quelchele', il quale frontend fa partire il vostro serverino personale.

Otterrete qualcosa che manca ancora di OLE, magari non sara' cosi' bello come Access,  ma sara' sempre qualcosa che ha ALTRI vantaggi, tipo il linguaggio sql,  e tutte le feature di un DBMS, che Access NON ha. (non essendo un DBMS , essenzialmente). Certo, e' un server che ti gira sulla macchina. Aha. Vogliamo parlare dell'efficienza un layer Odbc, invece?

Potrei continuare col mondo GNu/Linux che insegue il resto del mondo nel campo del messaging pur avendo gia' una sequela  di IRC server stabili, sicuri, robusti, cui mancano solo client grafici decenti, ad un NFS che ha perso lo scontro perche' nessuno ha mai scritto un client decente per windows, ad un mondo Gnu/Linux che insegue  penosamente Exchange quando dispone gia' di server smtp/imap/ftp/nntp/rsync  , e impacchettando insieme tutte queste cose (e scrivendo un frontend grafico sia per il client che uno per la configurazione) si poteva gia' contrastare Microsoft nel campo della collaborazione aziendale senza inventare improbabili framework ed improbabili "soluzioni enterprise", che dovevano riscrivere tutto lo stack.

 

Ci stiamo rendendo conto che se impacchettati insieme, postfix/imap/ftpd/innd/rsync/slapd , con l'aggiunta di qualche BUON frontend grafico  per la  configurazione , potevano avere da dire la loro?  Vogliamo parlare di un sistema operativo che ha bash/csh/tcl-tk/perl/awk (e un altro gazzilione) e insieme .... un pacchetto office che ancora non ha un linguaggio efficiente per le macro?E ci si fa battere da VB (BASIC!) come se su Linux non esistessero gia' compilatori di mezza dozzina di linguaggi ed interpreti a iosa? Davvero bisogna reinventare qualcosa?

ovviamente il risultato e' patetico. Dovendo ricominciare tutto da zero, senza i mezzi di Microsoft, tutto quello che si e' ottenuto SNOBBANDO L' ESISTENTE e' di ottenere un prodotto che fa MENO di Microsoft nei campi ove Microsoft eccelle, ma non fa DI MEGLIO nel campo ove, tuttavia, di eccellenza ne esisteva parecchia!

Per questa ragione, pur usando solo software OSS a casa,  non sono mai cosi' battagliero quando si parla dell' OpenSource nella PA. Si sta proponendo alla PA di ridurre i costi di licenza - che non incidono cosi' tanto sul CoO - in cambio di software che ... fa meno cose.

Il che sarebbe accettabile se con Gnu/Linux non arrivasse anche software che fa DI PIU', con il solo difetto di avere una interfaccia testuale, cosa per la quale si poteva pero' usare l' approccio "Lyx", e ottenere qualcosa di diverso, ma nel proprio campo imbattibile. Con Linux arrivano a corredo  27.000 programmi con interfaccia testuale. Se escludiamo i software per la masterizzazione, il "desktop linux" medio ne usa... uhm. Zero.

Non posso proporre Openoffice/Writer come alternativa a Word se Word fa le stesse cose e anche di piu'. Dov'e' il risparmio di tempo? Qual'e' il pro? Boh.

Ma posso proporre un ipotetico Lyx "on steroids" al posto di Word se dico "si, perdi tempo perche' manca questo e quello, ma lo recuperi con l'impaginazione e la qualita' editoriale". Allora si guarda quanto tempo si risparmia col copia incolla e quanto ad impaginare. Allora andiamo in una discussione.

Posso vendere un buon frontend grafico di R/Octave al posto di Excel, dicendo : si, non fa tutto quello che fa Excel come grafica e OLE, ma Excel come software statistico non fa tutto quello che fa R e come formule non arriva a Octave, e la sua capacita' di fare grafici e' peggiore di gnuplot.

E allora si discute. 

Se linux e' cosi' diffuso come server e come sistema con interfaccia  a caratteri, e poi col nome di Android vince a patto di rifare il frontend grafico, il messaggio e' chiaro: quel che c'e' sotto va benone, vanno scritti i frontend.

Ma chi ha scritto il desktop di linux (gnome o Kde, xfce ed altro) e tutto lo stack  ha ricominciato da capo, snobbando quel che c'era prima, col risultato che oggi insegue Microsoft sulle features, nonostante il fatto che "sotto", nell' OS, ci sia una minera di features SUPERIORI che aspettano solo un frontend grafico.

Se prendo qualsiasi desktop di linux e mi chiedo quanto usi il resto del patrimonio precedente , la risposta e' : praticamente zero. 

Questo approccio, a mio modesto parere sbagliato, ha portato ad un sistema inferiore dal punto di vista dell'utente, e quel che fa rabbia e' che se solo andiamo "sotto" i soliti "gnome/kde/OpenOfficeMozillaBlabLa ci sono dei backend (ad interfaccia testuale) ancora capaci di tirare calcioni.

Mancava solo l'interfaccia grafica. Certo, R, Octave&co hanno le loro interfacce. Ma il mondo intero vuole un'interfaccia come quella di Office. Vuole i numeri in una cosa che assomigli ad excel. E allora dateglieli.

Del resto, se osservate bene un computer apple, spesso trovate normalissimi comandi Unix invocati dall'interfaccia grafica di Apple. Gnu/Linux arriva con un corredo di software da invocare MOLTO piu' grande. Le funzionalita' esistevano gia', perche' reinventare la ruota?

In ultima ratio, credo che il desktop Linux iniziera' ad essere competitivo solo quando qualcuno cerchera' di recuperare la "Unix Way", o "Linux Way", e iniziera' a sviluppare il desktop come interfaccia al gigantesco patrimonio di sofware testuale, affidabile, complesso, testato, efficiente, POTENTE, che gira "sotto" la veste grafica.

Pensateci: quando scrivo usando Lyx, ad impaginare non ci penso proprio. Lo fara' poi il backend di LaTeX . Ma Lyx non fa parte di OpenOffice, ha pochi volontari per lo sviluppo, ed e' sostituito da una pessima imitazione di Microsoft Word 6.0, che pero' ha gli stessi difetti di Microsoft Word quando si parla di impaginare. E quando mi serve un modello di documento , uso quelli di LaTeX, che sono migliaia e migliaia, non quelli di LibreOffice. Sempre per lo stesso motivo : e' roba consolidata, funziona, predicibile, e Word non ci arrivera' mai, o quasi.

E cosi' la domanda che dovrebbe far riflettere e': perche' mai Openoffice non contiene un frontend grafico a LaTeX anziche' una ridicola imitazione di MS Word 6.0?

Hanno disegnato uno stack di programmi per il "Desktop Linux" come se sotto NON ci fosse la dotazione di software comunemente pacchettizzata con  linux. In pratica, hanno perso tutti i vantaggi, e hanno inseguito Microsoft dove era forte.  Chissa' come mai hanno perso, eh?

Ovviamente lo scontro e' sempre questo: chi sa quello che puo' fare il patrimonio di software OSS in modalita' testuale, si chiede quale sia il bisogno di reinventare tutto scrivendo pacchetti office da zero: se conoscete la potenza di LaTeX, SciLab,Octave,R, Emacs e tutto quanto, non capite perche' vi trovate con un pacchetto "Open/LibreOffice" che non li usa, e quando avete tutto il mondo di server disponibili per Unix e Linux, non capite per quale motivo ostinarsi a inseguire Exchange anziche' creare un frontend grafico per un bel pacchettone di server , e poi  un client multiprotocollo - per il quale esistono - e gia' questo fa pensare - librerie stabilissime. Quando vedo Blender mi viene da chiedermi se non sarebbe stato meglio un frontend , dall'aspetto identico, di Xpov.

Ed e' qui che nasce il mio atteggiamento , riguardo alla contesa stessa, di "fare il mio lavoro al lavoro, e non insistere molto fuori" : essenzialmente, se cercate di suggerire a  qualcuno che  il desktop Linux non funziona perche' NON E' FATTO PER LINUX , dal momento che  ne ignora completamente i  potentissimi backends testuali,i talebani di linux non capiscono nemmeno che cosa diciate.

Che poi si possano generare grafici per le slide usando gnuplot, e che vengano molto meglio di quelli di excel, e di OO Calc, beh, non lo capiscono.

Tanto hanno la seconda partizione con Windows.

Cosa sarebbe cambiato usando un "Approccio Lyx" nella PA? Se per voi la PA e' l'anagrafe, niente.

Ma se andiamo , che so, da Arpa con un excel che usa R come backend, e Arpa di statistiche "ne fa abbastanza", forse Microsoft si sarebbe trovata in difficolta' a fare un Excel potente come R. E magari potevamo avere un posto ove avremmo vinto con l' OSS, ma non per i costi. Per le feature.

Avete mai voluto , tanto per chiedere, che l' OSS vincesse per le features, e non "perche' si risparmia la licenza"?

Uhm.

NO.