Slug e unisi
Da Wikipedia, l'enciclopedia libera.
Revisione 09:20, Mag 16, 2007 Y.m (Discussione | contributi) Partecipanti ← Go to previous diff |
Versione attuale Hawk (Discussione | contributi) |
||
Riga 43: | Riga 43: | ||
=Incontri previsti= | =Incontri previsti= | ||
===21/05/2007=== | ===21/05/2007=== | ||
+ | ====Appuntamenti==== | ||
+ | #Visto che è un lunedì propongo di trovarsi allo [http://maps.google.it/maps?f=q&hl=it&q=Piazza+Calabria,+18%2F19+Siena+&sll=43.343329,11.312871&sspn=0.007085,0.017209&ie=UTF8&ll=43.333981,11.308451&spn=0.028343,0.068836&z=14&om=1 Skile'] (Piazza Calabria, 18/19) alle 21:30 -22:00 | ||
+ | #Per chi non sa come raggiungere vico alto io parto da porta ovile alle 21:20 circa. Se mi mandate una mail privata...ho 3/4 posti in auto. | ||
+ | |||
====Partecipanti==== | ====Partecipanti==== | ||
#--[[Utente:Hawk|Hawk]] | #--[[Utente:Hawk|Hawk]] | ||
#--[[Utente:Pragma|Pragma]] (se possibile) | #--[[Utente:Pragma|Pragma]] (se possibile) | ||
#--[[Utente:Dinogen|Marcello Semboli]] (se possibile) | #--[[Utente:Dinogen|Marcello Semboli]] (se possibile) | ||
- | #--[[Utente:Blackhat|Blackhat]] (se possibile) | + | #--[[Utente:Blackhat|Blackhat]] (al 99%) |
#--Yusef | #--Yusef | ||
+ | #--[[Utente:Steko|Steko]] (dopo le 21) | ||
+ | #--Freeze (devo solo fare mente locale :) ) | ||
+ | #--[[Utente:iakko|iakko]] (forse) | ||
+ | #--[[Utente:gabrimonfa|gabrimonfa]] | ||
+ | |||
+ | ====Resoconto==== | ||
+ | Ringrazio tutti quelli che hanno ieri sera partecipato | ||
+ | Sto preparando il documento per la commissione, ma ovviamente mi accorgo di avere bisogno di una mano. | ||
+ | Per iniziare sto cominciando a mettere in ordine ed in forma di bozza le idee di ieri sera che riassumo qui per chi non ha potuto partecipare e come promemoria per gli altri. Se scordo qualche punto... ditelo pure. | ||
+ | |||
+ | L'idea fondamentale di ieri sera mi è parso sia stata questa: dobbiamo fare far come l'arciere del Machiavelli che mira in alto sapendo ce poi la freccia scenderà e colpirà più in basso. | ||
+ | |||
+ | Il "cavalo di troia" che ci permetterà di farsi prendere in considerazione è sicuramente la possibilità di risparmiare organizzando una graduale migrazione da software proprietario a FLOSS, possibilmente senza perdere nessuna funzionalità o garanzia di supporto e forse gudangando qualcosa sotto altri punti di vista. | ||
+ | Per rendere questa migrazione appetibile all'utente finale ed a politici ed amministratori dell'ateneo si cercherà proporre un percorso di migrazione graduale, non coercitivo (quindi volontario) che però permetta di raggiungere e sanare per prime le maggiori emorragie in termini di risorse: si partirà dal proporre agli utenti/dipartimenti dell'ateneo la possibilità di impiegare una suite da ufficio FLOSS al posto di analoghi prodotti commerciali. | ||
+ | Come detto l'idea è di non imporre nulla a nessuno. Il passaggio deve avvenire su base volontaria: al momento in cui il dipartimento X, che ha fondi pari a pari a Y, ma necessita di ulteriori fondi Z, si potrà proporre ad X di introdurre software FLOSS per ottenere Z (o parte di Z) grazie al risparmio sulle licenze. | ||
+ | |||
+ | Perché quanto fino a qui detto possa funzionare sono necessari due accorgimenti: incentivare gli utenti dell'ateneo ad usare la suite FLOSS (con uno stratagemma) e prevedere in anticipo la possibilità di avere problemi di migrazione. | ||
+ | |||
+ | Partendo dal secondo punto, si è pensato di formare una specie di LUG all'interno dell'università (magari una branca dello SLUG) composto da personale dell'università addetto a risolvere i problemi tecnici legati alla migrazione e da volontari "di supporto" in grado di aiutare gli utenti con problemi comuni o banali. Questi volontari sarebbero l'equivalente della comunità FLOSS, ma essendo all'interno dell'università avrebbero la possibilità di essere fisicamente più vicini agli utenti in difficoltà. | ||
+ | Oltre a questo vanno censite e messe in contatto con l'università le realtà piccole | ||
+ | |||
+ | L'altro punto al quale si è pensato è quello di rendere il passaggio appetibile realizzando una personalizzazione di OpenOffice: si vuole proporre un OpenUnisiOffice da realizzarsi semplicemente sia cambiando nome, logo e documenti di esempio sia aggiungendo documentazione specifica all'ateneo ("come scrivere una buona tesi", "come usare il layout che stampa sulla carta intestata dell'ateneo"). | ||
+ | Passare ad una suite diversa non è mai un passaggio indolore, per farlo fare ai propri clienti (che oltretutto pagano per l'upgrade) le grandi software house sfruttano la loro immagine. | ||
+ | Passare ad un prodotto "gratuito" al fine di risparmiare può essere una cosa negativa per la propria l'immagine, ma passare da un determinato software sviluppato oltre oceano alla suite da ufficio ufficiale dell'ateneo, realizzata (personalizzata) a Siena a misura di dipendenti ed utenti dell'ateneo stesso e messa a disposizione gratuitamente da lungimiranti amministratori è tutta un'altra cosa. | ||
+ | Il lavoro che una simile personalizzazione richiede è davvero poco e porta con se un notevole numero di utili effetti collaterali tra cui | ||
+ | * un buon ritorno di immagine (sulla stampa ad esempio: "L'ateneo senese realizza la propria suite da ufficio", "L'ateneo senese all'avanguardia nell'adozione di software open source"), | ||
+ | * la possibilità di avere una suite da ufficio di riferimento *condivisa* da molti dipartimenti (con un notevole sgravio di lavoro per i tecnici grazie alla standardizzazione intra/infra-dipartimentale), | ||
+ | * la possibilità di risovere bug, aggiungere o modificare funzionalità secondo esigenze specifiche dell'ateneo (sviluppo di plugin per "pubblicazione immediata" dei documenti sui siti istituzionale, integrazione con software e servizi,anche commerciali, sviluppati dall'ateneo, come progetto di ricerca, o dalle sue spin off ad esempio per il "question answering") | ||
+ | * la possibilità di vendere o condividere il know-how acquisito ad altri atenei con esigenze simili (magari attivando progetti di collaborazione per ridurre i costi condividendo parti dello sviluppo) | ||
+ | |||
+ | Parallelamente all'adozione ed alla distribuzione centralizzata di OpenUnisiOffice si potranno gradualmente proporre altri strumenti FLOSS (firefox, octave, kvirc, gimp, scribus, linux...) personalizzati secondo gli stessi criteri utilizzati in OpenUnisiOffice. | ||
+ | |||
+ | --[[Utente:Hawk|Hawk]] 14:25, Mag 22, 2007 (BST) | ||
+ | |||
+ | ====Documenti allegati==== | ||
+ | *[http://www.openoffice.org/product/docs/ms2007vsooo2.pdf MSOffice 2007 vs OOO2 ] | ||
+ | *[http://www.cnipa.gov.it/site/_files/Studio_strumenti_office.pdf Comparazione tra suite di produttività individuale Rapporto del gruppo di lavoro] del CNIPA (Centro Nazionale per l'Informatica nella Pubblica Amministrazione] | ||
+ | *[http://documentation.openoffice.org/manuals/oooauthors2/0600MG-MigrationGuide.pdf Guida per la migrazione] | ||
+ | *[http://docs.google.com/Doc?id=dhgcx299_4cnn2jk Bozza del documento prodotto] | ||
---- | ---- |
Versione attuale
Table of contents |
Commissione per l'informatizzazione
Ho appena accettato di curare l'aspetto "open source" all'interno della commissione sull'informatizzazione dell'ateneo di cui faccio parte.
La commissione sta cercando di organizzare le "risorse informatiche": al momento tutto ciò che riguarda l'informatica, è "gestito" in maniera non coerente da una serie di "livelli burocratici". In sostanza mancano strategie comuni e coordinazione nella scelta di soluzioni tecniche, di accordi commerciali ed anche nella gestione dei fondi al capitolo "informatica".
Il primo atto della commissione è quello di stilare documento fotografia della situazione in modo da evidenziare i problemi dell'ateneo e le possibili strade da percorrere per risolverli.
Il capitolo riguardante l'open source lo sciverò io. I punti cruciali di questo capitolo saranno:
- la assoluta praticabilità dell'approccio "software libero"
- il risparmio possibile
- l'enorme vantaggio derivante dall'essere una grande realtà: con il budget
per 100 licenze windows+office pago un developer di openoffice per fargli customizzare quello che voglio o per risolvere qualsiasi problema (bug)
- l'aspetto etico: sicurezza (per i dati personali), vendor independence,
formati aperti...
Inoltre mi è stato richiesto uno studio comparativo OpenOffice vs MSOffice.
Il motivo di questa e-mail è che mi piacerebbe molto avere l'appoggio "ufficiale" del LUG ed un contributo fattivo da parte di chi può. Chiunque è benvenuto: non importa essere nell'università... Sono assolutamente utili contributi su
- esperienze di migrazioni al software libero
- esperienza su assistenza in ambito software libero
- contatti con aziende sul territorio in grado "eventualmente" di operare nel
settore
Propongo di trovarci (in stile hacknight o birrata) per parlarne insieme. Decidiamo una sera. Poi decidiamo come lavorare insieme ad una bozza/elenco di punti.
--Hawk 23:34, Mag 15, 2007 (BST)
Incontri previsti
21/05/2007
Appuntamenti
- Visto che è un lunedì propongo di trovarsi allo Skile' (http://maps.google.it/maps?f=q&hl=it&q=Piazza+Calabria,+18%2F19+Siena+&sll=43.343329,11.312871&sspn=0.007085,0.017209&ie=UTF8&ll=43.333981,11.308451&spn=0.028343,0.068836&z=14&om=1) (Piazza Calabria, 18/19) alle 21:30 -22:00
- Per chi non sa come raggiungere vico alto io parto da porta ovile alle 21:20 circa. Se mi mandate una mail privata...ho 3/4 posti in auto.
Partecipanti
- --Hawk
- --Pragma (se possibile)
- --Marcello Semboli (se possibile)
- --Blackhat (al 99%)
- --Yusef
- --Steko (dopo le 21)
- --Freeze (devo solo fare mente locale :) )
- --iakko (forse)
- --gabrimonfa
Resoconto
Ringrazio tutti quelli che hanno ieri sera partecipato Sto preparando il documento per la commissione, ma ovviamente mi accorgo di avere bisogno di una mano. Per iniziare sto cominciando a mettere in ordine ed in forma di bozza le idee di ieri sera che riassumo qui per chi non ha potuto partecipare e come promemoria per gli altri. Se scordo qualche punto... ditelo pure.
L'idea fondamentale di ieri sera mi è parso sia stata questa: dobbiamo fare far come l'arciere del Machiavelli che mira in alto sapendo ce poi la freccia scenderà e colpirà più in basso.
Il "cavalo di troia" che ci permetterà di farsi prendere in considerazione è sicuramente la possibilità di risparmiare organizzando una graduale migrazione da software proprietario a FLOSS, possibilmente senza perdere nessuna funzionalità o garanzia di supporto e forse gudangando qualcosa sotto altri punti di vista. Per rendere questa migrazione appetibile all'utente finale ed a politici ed amministratori dell'ateneo si cercherà proporre un percorso di migrazione graduale, non coercitivo (quindi volontario) che però permetta di raggiungere e sanare per prime le maggiori emorragie in termini di risorse: si partirà dal proporre agli utenti/dipartimenti dell'ateneo la possibilità di impiegare una suite da ufficio FLOSS al posto di analoghi prodotti commerciali. Come detto l'idea è di non imporre nulla a nessuno. Il passaggio deve avvenire su base volontaria: al momento in cui il dipartimento X, che ha fondi pari a pari a Y, ma necessita di ulteriori fondi Z, si potrà proporre ad X di introdurre software FLOSS per ottenere Z (o parte di Z) grazie al risparmio sulle licenze.
Perché quanto fino a qui detto possa funzionare sono necessari due accorgimenti: incentivare gli utenti dell'ateneo ad usare la suite FLOSS (con uno stratagemma) e prevedere in anticipo la possibilità di avere problemi di migrazione.
Partendo dal secondo punto, si è pensato di formare una specie di LUG all'interno dell'università (magari una branca dello SLUG) composto da personale dell'università addetto a risolvere i problemi tecnici legati alla migrazione e da volontari "di supporto" in grado di aiutare gli utenti con problemi comuni o banali. Questi volontari sarebbero l'equivalente della comunità FLOSS, ma essendo all'interno dell'università avrebbero la possibilità di essere fisicamente più vicini agli utenti in difficoltà. Oltre a questo vanno censite e messe in contatto con l'università le realtà piccole
L'altro punto al quale si è pensato è quello di rendere il passaggio appetibile realizzando una personalizzazione di OpenOffice: si vuole proporre un OpenUnisiOffice da realizzarsi semplicemente sia cambiando nome, logo e documenti di esempio sia aggiungendo documentazione specifica all'ateneo ("come scrivere una buona tesi", "come usare il layout che stampa sulla carta intestata dell'ateneo"). Passare ad una suite diversa non è mai un passaggio indolore, per farlo fare ai propri clienti (che oltretutto pagano per l'upgrade) le grandi software house sfruttano la loro immagine. Passare ad un prodotto "gratuito" al fine di risparmiare può essere una cosa negativa per la propria l'immagine, ma passare da un determinato software sviluppato oltre oceano alla suite da ufficio ufficiale dell'ateneo, realizzata (personalizzata) a Siena a misura di dipendenti ed utenti dell'ateneo stesso e messa a disposizione gratuitamente da lungimiranti amministratori è tutta un'altra cosa. Il lavoro che una simile personalizzazione richiede è davvero poco e porta con se un notevole numero di utili effetti collaterali tra cui
- un buon ritorno di immagine (sulla stampa ad esempio: "L'ateneo senese realizza la propria suite da ufficio", "L'ateneo senese all'avanguardia nell'adozione di software open source"),
- la possibilità di avere una suite da ufficio di riferimento *condivisa* da molti dipartimenti (con un notevole sgravio di lavoro per i tecnici grazie alla standardizzazione intra/infra-dipartimentale),
- la possibilità di risovere bug, aggiungere o modificare funzionalità secondo esigenze specifiche dell'ateneo (sviluppo di plugin per "pubblicazione immediata" dei documenti sui siti istituzionale, integrazione con software e servizi,anche commerciali, sviluppati dall'ateneo, come progetto di ricerca, o dalle sue spin off ad esempio per il "question answering")
- la possibilità di vendere o condividere il know-how acquisito ad altri atenei con esigenze simili (magari attivando progetti di collaborazione per ridurre i costi condividendo parti dello sviluppo)
Parallelamente all'adozione ed alla distribuzione centralizzata di OpenUnisiOffice si potranno gradualmente proporre altri strumenti FLOSS (firefox, octave, kvirc, gimp, scribus, linux...) personalizzati secondo gli stessi criteri utilizzati in OpenUnisiOffice.
--Hawk 14:25, Mag 22, 2007 (BST)
Documenti allegati
- MSOffice 2007 vs OOO2 (http://www.openoffice.org/product/docs/ms2007vsooo2.pdf)
- Comparazione tra suite di produttività individuale Rapporto del gruppo di lavoro (http://www.cnipa.gov.it/site/_files/Studio_strumenti_office.pdf) del CNIPA (Centro Nazionale per l'Informatica nella Pubblica Amministrazione]
- Guida per la migrazione (http://documentation.openoffice.org/manuals/oooauthors2/0600MG-MigrationGuide.pdf)
- Bozza del documento prodotto (http://docs.google.com/Doc?id=dhgcx299_4cnn2jk)