Software gestionale a licenza pubblica
Gabriele Del Giovine
>consentendo modifiche e successive distribuzioni con ląunico vincolo di
>applicare a queste le medesime condizioni previste dalla GGPL.
>GGPL non implica necessariamente che la distribuzione del software, e
>tantomeno la fornitura dei servizi ad esso correlati, debba avvenire in
>forma gratuita. Semplicemente prevede che nessuno possa porre dei vincoli o
>delle restrizioni di qualsiasi genere sul software coperto dalla licenza e
>sui prodotti da esso derivati.
C'č una lieve idiosincrasia fra i due punti. Forse il modello piů opportuno
di licenza
e la GPL limitata.
Saluti.
Piero Cavina
>Con questo post vorrei sollecitare una discussione pubblica sulla
>possibilità (e prima ancora sulla opportunità) di realizzare un software per
>la gestione aziendale secondo un modello di sviluppo cooperativo e
In generale mi sembra un'ottima idea, soprattutto perche' farebbe
chiarezza in un ambito dove mi sembra che ce ne sia poca: es. un
azienda commissiona personalizzazioni e le paga con relativa tariffa,
queste vengono successivamente inserite nel prodotto standard della
SH, che viene venduto ad altri; in seguito l'azienda iniziale compra
un aggiornamento del pacchetto e si ritrova anche le novita', che non
sono altro che "personalizzazioni" pagate da altri. Un bel modo di
raccontarsi delle balle attorno alla parola "personalizzazione".
Invece, le aziende interessate che possiedono lo stesso pacchetto e
condividono le stesse esigenze (in un distretto industriale questo e'
facilissimo) potrebbero mettersi d'accordo, e commissionare alla SH,
con una licenza pubblica precisa, lo sviluppo delle nuove
funzionalita'.
Le personalizzazioni dovrebbero restare solo che esattamente il nome
suggerisce, cioe' cose che non escono dalla porta del committente.
Un problema non piccolo, e' che data la complessita' dei gestionali
attuali dubito che si possa partire da zero, dovrebbe invece essere
una SH che rompe il ghiaccio rendendo pubblico il proprio prodotto.
Ciao,
P. Welcome to the previous level!
__________________________________________________________
(Replace "punto" with "." to get my real email address.)
Mumix
possibilità (e prima ancora sulla opportunità) di realizzare un software per
la gestione aziendale secondo un modello di sviluppo cooperativo e
General Public License (in seguito GGPL, www.gnu.org).
Lıidea nasce dallıosservazione della progressiva affermazione di Linux e dei
prodotti e dei servizi ad esso collegati. La qualità raggiunta e
lıaffidabilità sempre maggiore che questi prodotti stanno acquisendo è
testimoniata anche dai recenti investimenti compiuti in questo settore da
aziende leader come IBM, Oracle o Netscape.
GGPL prevede la libera distribuzione del software e di tutti i sorgenti,
consentendo modifiche e successive distribuzioni con lıunico vincolo di
applicare a queste le medesime condizioni previste dalla GGPL.
GGPL non implica necessariamente che la distribuzione del software, e
tantomeno la fornitura dei servizi ad esso correlati, debba avvenire in
forma gratuita. Semplicemente prevede che nessuno possa porre dei vincoli o
delle restrizioni di qualsiasi genere sul software coperto dalla licenza e
sui prodotti da esso derivati.
Per modello di sviluppo cooperativo e distribuito intendo che la
realizzazione del software dovrebbe essere eseguita da un gruppo abbastanza
numeroso di persone suddivise in gruppi di lavoro che si occuperebbero dello
sviluppo di singole parti o funzioni, coordinati da un gruppo ristretto di
coordinatori che avrebbero la responsabilità dellıanalisi e della conduzione
del progetto.
La partecipazione al progetto a qualunque livello sarebbe su base volontaria
e non retribuita; struttura, procedure e modalità operative e decisionali
sarebbero uno dei primi temi da affrontare da parte del gruppo di
coordinamento.
Perché realizzare un software gestionale a licenza pubblica ?
A mio avviso i motivi sono numerosi e credo possa essere quantomeno
intrapresa la valutazione della fattibilità di un tale progetto (posto che
si riesca ad interessare fin dalle prime fasi un numero sufficientemente
elevato di persone).
In una prima fase si dovrebbe concentrare il lavoro sugli aspetti di
carattere generale per valutare la fattibilità complessiva del progetto,
quali ad esempio:
a) Esistono progetti analoghi in Italia o allıestero ?
b) Ci sono persone in Italia che stiano partecipando a progetti simili (come
Linux, Gnome o altri) ed è possibile fare riferimento alla loro esperienza ?
c) Dovrebbe essere un progetto nazionale o internazionale (tenendo conto
delle forti localizzazioni richieste per questo genere di software) ?
d) Quante persone sarebbe necessario coinvolgere per contenere i tempi?
e) Quale modello di licenza adottare ?
In una seconda fase, qualora la prima sortisca un riscontro positivo,
dovrebbero essere organizzati uno o più gruppi di discussione per affrontare
tematiche quali:
a) Come iniziare lıanalisi e la stesura delle specifiche funzionali ?
b) Come, e con quali strumenti, organizzare la collaborazione ?
c) Come organizzare lo sviluppo ?
d) Quale ambiente di sviluppo utilizzare ?
e) Quale o quali linguaggi ?
In questa prima fase preliminare tutti i commenti, suggerimenti o critiche
(anche le più negative) possono essere inviati all'indirizzo mu...@libero.it
Qualora questa proposta susciti interesse e dai primi riscontri emerga la
possibilità quantomeno di tentare un approfondimento delle numerose
tematiche coinvolte, mi impegno ad attivare una sede opportuna per iniziare
la seconda fase di discussione (mailing list o altro) o a consegnare il
materiale raccolto a qualcuno interessato alla prosecuzione del progetto.
Mumix
freddy kruger
Piero Cavina <p.ca...@mopuntonettuno.it> wrote in message
>es. un
> azienda commissiona personalizzazioni e le paga con relativa tariffa,
> queste vengono successivamente inserite nel prodotto standard della
> SH, che viene venduto ad altri; in seguito l'azienda iniziale compra
> un aggiornamento del pacchetto e si ritrova anche le novita', che non
> sono altro che "personalizzazioni" pagate da altri.
Oltre il danno la beffa: molto spesso per le personalizzazioni all'inizio
bisogna "pregare" la software house e in virtù della vendita successiva che
questa già progetta, bisogna anche convicerla dell'utilità delle
personalizzazioni stesse.
> Ciao,
Ciao (ma sei lo stesso Piero Cavina di it.arti.trash?)
CED
Mumix ha scritto:
>
> Con questo post vorrei sollecitare una discussione pubblica sulla
> possibilità (e prima ancora sulla opportunità) di realizzare un software per
> la gestione aziendale secondo un modello di sviluppo cooperativo e
> distribuito e soggetto alle regole di una licenza pubblica come la GNU
> General Public License (in seguito GGPL, www.gnu.org).
>
Di primo impulso ritengo l'idea meritevole ma un po' utopistica perche'
trovare il "minimo comune multiplo" di tutte le esigenze, per molte
tipologie diverse di azienda (in base alle dimensioni, al settore
merceologico, ecc.) sara' una impresa ardua.
> A mio avviso i motivi sono numerosi e credo possa essere quantomeno
> intrapresa la valutazione della fattibilità di un tale progetto (posto che
> si riesca ad interessare fin dalle prime fasi un numero sufficientemente
> elevato di persone).
Per realizzare un progetto di questo tipo e' sicuramente necessario
coinvolgere un numero di persone molto elevato; la disponibilita' a
collaborare ad un progetto di questo tipo è sicuramente condizionata
anche dagli strumenti adottati, quindi cercherei di anticipare la loro
scelta.
Certamente partire da una base già sviluppata (San Francisco batti un
colpo) aiuterebbe!!!!!
...........................................
Stefano
Ferrari Dario
Mumix ha scritto nel messaggio <82upuk$7k7$4...@nslave1.tin.it>...
>Con questo post vorrei sollecitare una discussione pubblica sulla
>possibilità (e prima ancora sulla opportunità) di realizzare un software per
>la gestione aziendale secondo un modello di sviluppo cooperativo e
>distribuito e soggetto alle regole di una licenza pubblica come la GNU
>General Public License (in seguito GGPL, www.gnu.org).
Velocemente..............e dichiarando la mia disponibiltà ad approfondire.
Progetto interessante ma un pò troppo ambizioso.
Non credo che le aziende utilizzatrici di software gestionale siano interessate
ad investire in un progetto di così ampio respiro.
Gli costerebbe meno ritagliarsi addosso un applicativo.
Le risorse da allocare poi mi sembrano notevoli.
Non credo che la mia azienda mi ceda volentieri per un progetto del genere
(non perchè io sia il massimo, ma perchè credo di servire nella gestione quotidiana).
Se aspetti la mia pensione, ti do la mia disponibilità personale a solo rimboso spese, altrimenti
.........................................
Chi traccierebbe le linee guida?
Quali sono le esigenze che tale applicativo dovrebbe coprire?
Bisogna darsi degli spazi ben delimitati.
Comunque hai sollevato un problema che ritengo reale e sentito.
D. Ferrari
Piero Cavina
> Di primo impulso ritengo l'idea meritevole ma un po' utopistica perche'
> trovare il "minimo comune multiplo" di tutte le esigenze, per molte
> tipologie diverse di azienda (in base alle dimensioni, al settore
> merceologico, ecc.) sara' una impresa ardua.
Nei cosiddetti distretti industriali, perň, potrebbe avere molto senso.
Bisogna vedere, perň, se esiste una cultura imprenditoriale sufifcientemente
ricettiva a ragionamenti di questo tipo (e qui ci si addentra in questioni
spinose...)
Diego Mazzola
> >Con questo post vorrei sollecitare una discussione pubblica sulla
> >possibilità (e prima ancora sulla opportunità) di realizzare un software
per
> >la gestione aziendale secondo un modello di sviluppo cooperativo e
Mi sembra molto improbabile poter realizzare un pacchetto di tale portata
"sui generis...".
Un conto è sviluppare un sistema operativo, un conto è un pacchetto
gestionale che, per sua stessa natura, deve svolgere dei compiti "vestiti su
misura" per l'azienda che si intende gestire.
Di solito il problema sul gestionale non è il costo iniziale quanto
l'istruzione che serve per farlo funzionare (vedi SAP) nella particolare
realtà aziendale che si vuole gestire.
Sinceramente, mi sembra veramente un'utopia .... già abbiamo problemi si
standard noi che siamo calati su un settore veramente molto particolare ....
> On Sun, 12 Dec 1999 01:16:42 +0100, "Mumix" <mu...@libero.it> wrote:
> In generale mi sembra un'ottima idea, soprattutto perche' farebbe
> chiarezza in un ambito dove mi sembra che ce ne sia poca: es. un
> azienda commissiona personalizzazioni e le paga con relativa tariffa,
> queste vengono successivamente inserite nel prodotto standard della
> SH, che viene venduto ad altri; in seguito l'azienda iniziale compra
> un aggiornamento del pacchetto e si ritrova anche le novita', che non
> sono altro che "personalizzazioni" pagate da altri. Un bel modo di
> raccontarsi delle balle attorno alla parola "personalizzazione".
> Invece, le aziende interessate che possiedono lo stesso pacchetto e
> condividono le stesse esigenze (in un distretto industriale questo e'
> facilissimo) potrebbero mettersi d'accordo, e commissionare alla SH,
> con una licenza pubblica precisa, lo sviluppo delle nuove
> funzionalita'.
> Le personalizzazioni dovrebbero restare solo che esattamente il nome
> suggerisce, cioe' cose che non escono dalla porta del committente.
Sono daccordo con te, le personalizzazioni sono personalizzazioni. Vorrei
spezzare una lancia nei confronti delle softwarehouse (visto che anch'io
...). Di Norma (e per legge) le personalizzazioni sono e restano
personalizzazioni di proprietà del cliente che le commissiona, semprechè il
contratto di sviluppo delle suddette non preveda accordi di altro genere. Un
altro problema che bisogna valutare è l'impatto delle personalizzazioni sul
pacchetto standard, il costo della personalizzazione non è il solo lavoro
per farla, ma anche il lavoro che servirà poi per mantenerla allienata con
il progredire delle versioni ....
Cmq, ammetto che ci sono softwarehouse che ci marciano alla grande
(soprattutto per ignoranza da parte dei clienti ....il che non giustifica la
cosa ovviamente ...).
> Un problema non piccolo, e' che data la complessita' dei gestionali
> attuali dubito che si possa partire da zero, dovrebbe invece essere
> una SH che rompe il ghiaccio rendendo pubblico il proprio prodotto.
Mi spieghi dove trovi un softwarehouse così "fuori di testa"? E' come
chiedere a qualcuna di regalare i propri brevetti ...
Ciao
--
Diego Mazzola
AS/400 Professional System Engineer & LAN Administrator
EMail di...@eidosistemi.block.it
(togliere "block" per inviare messaggi - Remove block to use this address)
Eidos Sistemi Informativi S.r.l.
Specialisti in Sistemi Informativi per Orafi, Argentieri e Gioiellieri
Via Nino Bixio, 43 - 36100 Vicenza - Italia
Tel. +39 0444 964304 Fax +39 0444 964304
Piero Cavina
94507816...@flesh.goldnet.it...
> > Un problema non piccolo, e' che data la complessita' dei gestionali
> > attuali dubito che si possa partire da zero, dovrebbe invece essere
> > una SH che rompe il ghiaccio rendendo pubblico il proprio prodotto.
> Mi spieghi dove trovi un softwarehouse così "fuori di testa"? E' come
> chiedere a qualcuna di regalare i propri brevetti ...
Le SH che guadagnano con l'open-source (o variazioni sul tema) ci sono già,
no? Inoltre, stiamo parlando di sistemi complessi, ma privi di particolari
"segreti tecnlologici" che hanno richiesto ingenti investimenti in r&s come
p.es. sw per il riconoscimento della voce o delle immagini..
Magari basterebbe una piattaforma di partenza neanche troppo sofisticata,
poi il resto verrebbe da sè (altre SH, e clienti che fanno sviluppo
interno). Il business sarebbe nelle consulenze, e nello sviluppo di
innovazioni su commissione di utenti-aziende che dovrebbero associarsi nel
fare le richieste alle SH. Inoltre forse aziende che oggi faticano (per
questioni economiche, o per (in)cultura) a spingere sull'informatizzazione,
potrebbero essere incentivate a farlo. Forse alla fine ne guadagnerebbero
tutti, SH e clienti. Chi può dirlo? :-)
Gabriele Del Giovine
Piero Cavina <p.cav...@spam-mo.nettuno.it> wrote in message
news:832j9l$o78$1...@serv1.iunet.it...
> potrebbero essere incentivate a farlo. Forse alla fine ne guadagnerebbero
> tutti, SH e clienti. Chi può dirlo? :-)
IBM per cominciare potrebbe ad esempio mettere in GPL il codice delle ACG.
Saluti.
Giancarlo Negroni
Gabriele Del Giovine <mc6...@mclink.it> wrote in message
> IBM per cominciare potrebbe ad esempio mettere in GPL il codice delle ACG.
E' la migliore battuta sentita nel '99
ciao
Giancarlo Negroni
Danilo Cussini
> In generale mi sembra un'ottima idea, soprattutto perche' farebbe
> chiarezza in un ambito dove mi sembra che ce ne sia poca: es. un
> azienda commissiona personalizzazioni e le paga con relativa tariffa,
> queste vengono successivamente inserite nel prodotto standard della
> SH, che viene venduto ad altri; in seguito l'azienda iniziale compra
> un aggiornamento del pacchetto e si ritrova anche le novita', che non
> sono altro che "personalizzazioni" pagate da altri. Un bel modo di
> raccontarsi delle balle attorno alla parola "personalizzazione".
Io ho lavorato in SH per 10 anni e adesso lavoro in una azienda, quindi
il problema delle personalizzazioni che finiscono nel prodotto standard
l'ho visto e gestito da entrambi i punti di vista.
Per la mia esperienza, le personalizzazioni che finiscono nello
standard vanno a tutto vantaggio del cliente che le ha commissionate,
per il semplice fatto che in questo modo il cliente ottiene il
risultato di ... non avere personalizzazioni. Questo lo pensavo quando
lavoravo in una SH, dove i clienti più importanti pretendavo che le
loro personalizzazioni fossero standard, e lo penso soprattutto adesso
che lavoro in uno di quei clienti importanti.
IMHO, questa visione diversa dipende dal rapporto che hai instaurato
con la tua SH: se la vedi come uno dei tanti fornitori, allora hai
ragione; ma se la vedi come il tuo partner nella gestione del sistema
informativo ...
Per quanto riguarda il discorso "chiarezza", il problema da te
sollevato deve essere risolto in fase di scrittura del contratto di
fornitura; infatti, noi facciamo inserire nei contratti la clausola che
tutti gli sviluppi commissionati devono finire nello standard.
--
- Non so voi, ma io era anni che non mi divertivo cosi'.
- Cos'erano?
- AAANNI ...
da "Marrakech Express"
Sent via Deja.com http://www.deja.com/
Before you buy.
Obelix
<mc6...@mclink.it> wrote:
>> IBM per cominciare potrebbe ad esempio mettere in GPL il codice delle ACG.
Stai scherzando, vero?? se lo pubblicano, avrebbero il maggior
successo comico del millennio, presente eprossimo, al punto da
offuscare sensibilmente la fama di Aldo, Giovanni e Giacomo :-))
Obelix
Piero Cavina
<lincen...@virgilio.it> wrote:
>
>Ciao (ma sei lo stesso Piero Cavina di it.arti.trash?)
>
Facile.. :-) ..ma ci avevate fatto caso che Obelix posta quasi il
triplo su it.sport.formula1 rispetto a questo gruppo? ;-)
Piero Cavina
<danilo...@my-deja.com> wrote:
>Per la mia esperienza, le personalizzazioni che finiscono nello
>standard vanno a tutto vantaggio del cliente che le ha commissionate,
>per il semplice fatto che in questo modo il cliente ottiene il
>risultato di ... non avere personalizzazioni.
Ottieni anche il risultato di avere direttamente finanziato ricerca e
sviluppo del SW, per la gioia dei tuoi concorrenti che compreranno la
versione standard. E di avere pagato per aumentare in know-how della
SH.
>IMHO, questa visione diversa dipende dal rapporto che hai instaurato
>con la tua SH: se la vedi come uno dei tanti fornitori, allora hai
>ragione; ma se la vedi come il tuo partner nella gestione del sistema
>informativo ...
Ma un rapporto di collaborazione dovrebbe basarsi su fiducia e
correttezza reciproca. Quindi, perlomeno non le si chiami
"personalizzazioni" ma "sviluppo in partnership del pacchetto
standard", e si pratichino tariffe diverse. Sempre per la serie: non
raccontiamoci balle.
Icci
p.ca...@mopuntonettuno.it wrote:
> On Mon, 13 Dec 1999 09:25:07 +0100, "freddy kruger"
> <lincen...@virgilio.it> wrote:
>
> >
> >Ciao (ma sei lo stesso Piero Cavina di it.arti.trash?)
> >
>
> Facile.. :-) ..ma ci avevate fatto caso che Obelix posta quasi il
> triplo su it.sport.formula1 rispetto a questo gruppo? ;-)
>
Ecco dove l'avevo visto !!!
Danilo Cussini
> Ottieni anche il risultato di avere direttamente finanziato ricerca e
> sviluppo del SW, per la gioia dei tuoi concorrenti che compreranno la
> versione standard.
Sě, ma č anche vero il contrario, cioč io beneficio degli sviluppi
pagati da altri, che sono sicuramente di piů di quelli che ho pagato io.
> E di avere pagato per aumentare in know-how della SH.
Che mi sta benissimo, perchč siamo partner nella conduzione del sistema
informativo.
> Ma un rapporto di collaborazione dovrebbe basarsi su fiducia e
> correttezza reciproca. Quindi, perlomeno non le si chiami
> "personalizzazioni" ma "sviluppo in partnership del pacchetto
> standard",
D'accordo.
> e si pratichino tariffe diverse.
Avevo dimenticato l'argomento tariffe: naturalmente, questi sviluppi
che finiscono nello standard hanno, almeno per noi, un prezzo
ampiamente scontato.
> Sempre per la serie: non raccontiamoci balle.
Il fatto che questi sviluppi saranno rivenduti ad altri, noi lo
sappiamo, quindi non ho ancora capito chi č che racconta delle balle e
quali sono queste balle. Se poi uno, sapendo queste cose, non č
sufficientemente scaltro da spuntare un buon prezzo ...
--
- Non so voi, ma io era anni che non mi divertivo cosi'.
- Cos'erano?
- AAANNI ...
da "Marrakech Express"
Mumix
delle questioni poste questa sera (il lavoro mi chiama, ahime !).
Per il momento una considerazione di carattere culturale.
Il post originale e' stato inviato a 7 NG italiani. Le risposte provengono
quasi tutte dai 2 NG AS/400.
Questo la dice lunga su quanto il software non sia solo "codice" ma anche, e
forse soprattutto, conoscenza dei problemi.
Con tutta evidenza, nel "mondo AS/400" la sensibilita' e la competenza
rispetto ai temi del software gestionale (perdonatemi questa definizione
indefinita) e' ancora di gran lunga superiore alla media del "mondo
informatico" italiano.
Anche questo sarebbe un bel tema di discussione.
Ciao
Mumix
Gabriele Del Giovine
Mumix <mu...@libero.it> wrote in message news:834svi$9af$2...@nslave2.tin.it...
> Grazie a tutti per le numerose risposte. Cerchero' di rispondere nel
merito
> delle questioni poste questa sera (il lavoro mi chiama, ahime !).
>
> Per il momento una considerazione di carattere culturale.
>
> Il post originale e' stato inviato a 7 NG italiani. Le risposte provengono
> quasi tutte dai 2 NG AS/400.
Per loro il mondo è solo internet e mp3....
Saluti.
Obelix
<p.ca...@mopuntonettuno.it> wrote:
>> ma ci avevate fatto caso che Obelix posta quasi il
>> triplo su it.sport.formula1 rispetto a questo gruppo? ;-)
Su ISF1 ci si diverte di piu'....
Obelix li' si cazzeggia il 99% del tempo..
Obelix
>> Ecco dove l'avevo visto !!!
"visto" mi sembra eccessivo .-))
Obelix
Icci
Hai ragione, ciao Ciro.
Gabriele Del Giovine
Obelix <n...@unitessile.it> wrote in message
news:GUf2Mcdc9kDW-pn2-40B6QWpZXIdY@localhost...
Allora mi perdo un sacco di risate non conoscendo l'RPG.....
Saluti.
Piero Cavina
8350c0$52n$1...@fe1.cs.interbusiness.it...
> > Il post originale e' stato inviato a 7 NG italiani. Le risposte
provengono
> > quasi tutte dai 2 NG AS/400.
> Pretendevi forse che i raggazzatti di it.comp.os.linux capissero la cosa?
> Per loro il mondo è solo internet e mp3....
Perchè tanto odio..? :-)
Gabriele Del Giovine
Saluti.
Obelix
<mc6...@mclink.it> wrote:
>> Allora mi perdo un sacco di risate non conoscendo l'RPG.....
Non ti preoccupare, ti faremo le recensioni.
Obelix
Obelix
<mc6...@mclink.it> wrote:
>> Perchč sono cattivo.....
. geneticamente
Obelix i fondamentali, cazzo (c)
Mauro Mariz
> >> triplo su it.sport.formula1 rispetto a questo gruppo? ;-)
> Su ISF1 ci si diverte di piu'....
>
> Obelix li' si cazzeggia il 99% del tempo..
Ma voi quando dormite (o lavorate) ???? Arrivo appena a seguire, per lavoro,
alcuni NG relativi all'informatica....
:-)))))
bye
Mauro Mariz
3nto
Obelix
wrote:
>> Ma voi quando dormite (o lavorate) ???? A
Fai anche tu un figlio, e vedi quanto dormi.... :-))
ad ogni modo, sui NG di tifo la lettura impegna molto meno :-9
Obelix
Mauro Mariz
> Fai anche tu un figlio, e vedi quanto dormi.... :-))
Già dato 2 volte, grazie..... in verità non mi hanno fatto perdere tante
notti, ed in ogni caso se devo "spupazzarli" di quà e là invece di dormire,
non posso contemporaneamente seguire l'NG: a loro del computer non
glienefreganiente (beati!!!)
bye
Mauro Mariz
3nto
Obelix
wrote:
>> ed in ogni caso se devo "spupazzarli" di quà e là invece di dormire,
>> non posso contemporaneamente seguire l'NG:
Il mio si e' limitato ad occupare il mio letto, e allora... :-))
Obelix
Mumix
> ... investire in un progetto di così ampio respiro.
> Gli costerebbe meno ritagliarsi addosso un applicativo.
> Le risorse da allocare poi mi sembrano notevoli.
> Non credo che la mia azienda mi ceda volentieri per un progetto del genere
> (non perchè io sia il massimo, ma perchè credo di servire nella gestione
> quotidiana).
L'idea originaria prevederebbe l'impiego di persone che partecipano su base
volontaria, non retribuita e a titolo personale (quindi fondamentalmente nel
tempo libero), senza richiedere necessariamente la partecipazione di
aziende, che peraltro sarebbero benvenute.
> Chi traccierebbe le linee guida?
> Quali sono le esigenze che tale applicativo dovrebbe coprire?
> Bisogna darsi degli spazi ben delimitati.
D'accordissimo per quanto riguarda la delimitazione degli spazi.
Ciao
Mumix
Mumix
> Di primo impulso ritengo l'idea meritevole ma un po' utopistica perche'
> trovare il "minimo comune multiplo" di tutte le esigenze, per molte
> tipologie diverse di azienda (in base alle dimensioni, al settore
> merceologico, ecc.) sara' una impresa ardua.
Sono d'accordo sul fatto che l'idea possa essere per molti versi utopica, ma
non necessariamente per quanto riguarda l'aspetto che tu rilevi: tutto
sommato sarebbe gia' un bel successo riuscire a realizzare un prodotto che
possa competere con i prodotti di fascia bassa rivolti alle piccole aziende
e che notoriamente non sono dei "mostri" di completezza.
> ... la disponibilita' a collaborare ad un progetto di questo
> tipo è sicuramente condizionata anche dagli strumenti adottati,
> quindi cercherei di anticipare la loro scelta.
Questo sarebbe certamente uno dei primi punti nell'agenda di una ipotetica
fase due, da avviare non qualora in questi giorni si riesca a raccogliere un
discreto numero di "adesioni".
> Certamente partire da una base già sviluppata (San Francisco batti un
> colpo) aiuterebbe!!!!!
C'e' qualcuno che conosca qualcosa in piu' su San Francisco rispetto a
quello che si puo' leggere sulle riviste (ad esempio che abbia partecipato
ai corsi di IBM) ? O che conosca qualcuno che conosce ?
Credo che San Francisco andrebbe senz'altro tenuto in grande considerazione.
Ciao
Mumix
Mumix
> Un conto è sviluppare un sistema operativo, un conto è un pacchetto
> gestionale che, per sua stessa natura, deve svolgere dei compiti "vestiti su
> misura" per l'azienda che si intende gestire.
> Di solito il problema sul gestionale non è il costo iniziale quanto
> l'istruzione che serve per farlo funzionare (vedi SAP) nella particolare
> realtà aziendale che si vuole gestire.
Installazione, addestramento e personalizzazioni sarebbero a cura di chi
decide di utilizzare il prodotto, non del gruppo di sviluppo. Credo che un
prodotto "open source" fornirebbe notevoli potenzialità in questo senso
soprattutto se sviluppato tenendo conto di questo.
D'altra parte e' un fatto che i "pacchetti" gestionali esistono: si
tratterebe solo di svilupparne un altro !
Ciao
Mumix
Mumix
> questo che Linux e' strapieno di compilatori, ma fino all'arrivo di *grandi
> gruppi* non aveva un pacchetto di office decente (e quello che e' arrivato,
> stranamente, non e' Open Source. Questo non ti fa pensare.
Mumble, mumble ...
> Molto meglio IMHO 'partire' con una serie di utility OS...
OK. Qualche idea ? Per quale OS ?
Naturalmente io partecipo solo se il progetto del gestionale non decolla ;-)
> Per me, buona la seconda. Come idea non e' affatto male, come base e'
> interessante (OS, al di la' di tutto e' una cosa che i programmatori seri
> dovrebbero fare...) ma l'idea di fare un gestionale e' troppo grossa.
Si potrebbe anche partire da una "cosa" che sta tra l'OS e il gestionale: un
framework applicativo. Magari anche in RPG, anche se attualmente mi sono
innamorato del object oriented.
Mumix
Mumix
(Gnu Enterprise); maggiori informazioni sul sito www.gnu.org
La segnalazione proviene da Davide Barbieri di Prosa (www.prosa.it), una
societa' che si occupa di software "open".
Mumix
Mumix
Ma dovranno pur crescere ! o no ?
Ciao
Mumix
Nell'articolo <8350c0$52n$1...@fe1.cs.interbusiness.it> , "Gabriele Del
Giovine" <mc6...@mclink.it> è stato scritto:
>> Per il momento una considerazione di carattere culturale.
>>
>> Il post originale e' stato inviato a 7 NG italiani. Le risposte provengono
>> quasi tutte dai 2 NG AS/400.
> Pretendevi forse che i raggazzatti di it.comp.os.linux capissero la cosa?
> Per loro il mondo è solo internet e mp3....
>
>
> Saluti.
Piero Cavina
>Si potrebbe anche partire da una "cosa" che sta tra l'OS e il gestionale: un
>framework applicativo. Magari anche in RPG, anche se attualmente mi sono
>innamorato del object oriented.
Ehi, no, basta! Se bisogna fare un gestionale nuovo, che lo si faccia
object oriented! :-)
Obelix
>> Ma dovranno pur crescere ! o no ?
Beh, fin che dall'altra parte si scontrano con i loro coetanei di it.comp.winxx,
non gli serve...
Obelix
Obelix
>> (quindi fondamentalmente nel tempo libero),
Wow,. Tu hai del tempo libero??? wonderful...
Obelix
Obelix
>> OK. Qualche idea ? Per quale OS ?
Il nome del newsgroup non ti suggersice nulla??? :-))
>> Si potrebbe anche partire da una "cosa" che sta tra l'OS e il gestionale: un
>> framework applicativo.
Beh, buona fortuna...
Obelix
Obelix
>> Se bisogna fare un gestionale nuovo, che lo si faccia
>> object oriented! :-)
Mah. Fare un gestionale user-oriented pare brutto???
Obelix
Rubicante
>(Gnu Enterprise); maggiori informazioni sul sito www.gnu.org
Anche questi http://www.linux-kontor.de/en/
hanno attivato un progetto di un gestionale con licenza pubblica
il problema è che sono tedeschi (vedi SAP) ed è scritto in JAVA
P.S. Mi sono ciucciato i MB dalla rete ma non ho ancora trovato un
momento per dargli un'occhiata
"Se non crei dopo aver pensato non pensare,
sprecheresti solo il tempo" (Trolley Man)
Ciao Eugenio Faenza
Piero Cavina
> >> Se bisogna fare un gestionale nuovo, che lo si faccia
> >> object oriented! :-)
> Mah. Fare un gestionale user-oriented pare brutto???
Era una battuta?
Obelix
<p.cav...@spam-mo.nettuno.it> wrote:
>> > Mah. Fare un gestionale user-oriented pare brutto???
>> Era una battuta?
Hai visto delle faccine???
Obelix
Piero Cavina
Che c'entra con l'OO?
Piero Cavina
> Segnalo a chi fosse interessato che esiste un progetto analogo chiamato
GNUE
> (Gnu Enterprise); maggiori informazioni sul sito www.gnu.org
Ho dato un'occhiata all'archivio della mailing list del progetto, relativo
al mese corrente.
Non si sono ancora messi d'accordo sul linguaggio da usare...
Obelix
wrote:
>> Che c'entra con l'OO?
Se non ci arrivi, e' inutile spiegartelo
Obelix
Gabriele Del Giovine
> >> object oriented! :-)
Saluti.
Piero Cavina
Non č che il GCN ha cambiato il gruppo in it.comp.os.astronzi? :-)
Dammi solo una chance. Vuoi dire una roba per tipo "la progettazione e
sviluppo ad oggetti lasciamola ai fighetti, alle cose serie ci pensiamo noi
uomini veri, sotto con la tastiera e pedalare"?
Obelix
<p.cav...@spam-mo.nettuno.it> wrote:
>> on č che il GCN ha cambiato il gruppo in it.comp.os.astronzi? :-)
Ma no, ma, no, e' solo che l'IBM ha mandato il mio 730 a firenze
invece che qui, e siamo un po' esagitati :-)))
>> Vuoi dire una roba per tipo "la progettazione e
>> sviluppo ad oggetti lasciamola ai fighetti, alle cose serie ci pensiamo noi
>> uomini veri, sotto con la tastiera e pedalare"?
Ci sei quasi. Vuol dire che invece di pensare a *come* fare il
pacchetto, pensiamo a fare un pacchetto che sia buono per gli utenti
(e, come ha detto gabriele, che funzioni). Poi, possiamo anche
scriverlo in Assembly, ma e' un fatto collaterale.
Ci sono in giro un sacco di pacchetto che pajono nato per far vedere
quant'e' figo er programmatore, invece che per poter essere usati bene
dagli utenti.-....
Obelix
Mumix
Ho appena il tempo di "vedere" la posta in arrivo ma non di leggerla !
Sabato saro' di ritorno. Tenetemi il thread in caldo ;-)
Ciao
Mumix
Stefano Sonzogni
>>> on è che il GCN ha cambiato il gruppo in it.comp.os.astronzi? :-)
>Ma no, ma, no, e' solo che l'IBM ha mandato il mio 730 a firenze
>invece che qui, e siamo un po' esagitati :-)))
Beh, ma allora queste vaccate sono un altro vizio di IBM... L'anno
scorso invece di consegnarmi 1 170 me ne sono arrivati 2... Il secondo
era destinato in Olanda ma e' arrivato qui in provincia di BG...
Ciao
Stefano.
Obelix
wrote:
>> L'anno
>> scorso invece di consegnarmi 1 170 me ne sono arrivati 2... I
Ah, io a febbraio di quest'anno ho ordinato due dischi aggiuntivi per
la 9337, e me ne sono arrivati sei, nessuno dei quali, comunque, era
il nostro....
Si vede che anche internamente all'IBM hanno iniziato ad usare NT,
eh??
Obelix
Gabriele Del Giovine
> Si vede che anche internamente all'IBM hanno iniziato ad usare NT,
> eh??
No, usano applicazioni client/server SQL con viste logiche fatte da RPG
invece che
da SQL.
Saluti.
Obelix
<mc6...@mclink.it> wrote:
>> No, usano applicazioni client/server SQL con
Ecco perche' si incasinano... dovevano usare DB2 :-))
Obelix
Roberto Icardi
Roberto Icardi
> Ci sei quasi. Vuol dire che invece di pensare a *come* fare il
> pacchetto, pensiamo a fare un pacchetto che sia buono per gli utenti
> (e, come ha detto gabriele, che funzioni). Poi, possiamo anche
> scriverlo in Assembly, ma e' un fatto collaterale.
>
Non discuto sul fatto che si puo' fare un OTTIMO prodotto in assembly...
ma a parita' di qualità di prodotto, una corretta ingegnerizzazione o/o ti
da ENORMI vantaggi a livello di manutenzione e modifica successiva....
certo, tu avrai le tue routine standard che riutilizzi in ogni programma, ma
non e' esattamente la stessa cosa...
Poi sul fatto che si possa fare un prodotto scarsamente manutenibile e
lontano dalle esigenze dell'utente con il linguaggio e/o l'ambiente di
sviluppo piu' figo del mondo è + che sicuro... del resto con gli stessi
attrezzi si puo' costruire una skoda o una porsche.. anzi diro' di piu': la
quantità di lamiera è quasi la stessa, è solo piegata diversamente :-)))
> Ci sono in giro un sacco di pacchetto che pajono nato per far vedere
> quant'e' figo er programmatore, invece che per poter essere usati bene
> dagli utenti.-....
>
In giro c'e' tutto e il contrario di tutto, quindi....
Obelix
>> E fare tutte e due le cose no ????
Si, basta che *prima* lo facciamo bene e *poi* lo facciamo figo. Di solito,
l'orientamento e' opposto :-))
Obelix che non ha nulla contro OOP, finche' rimane un mezzo...
Roberto Icardi
solito,
> l'orientamento e' opposto :-))
>
> Obelix che non ha nulla contro OOP, finche' rimane un mezzo...
Neanche su questo
Mumix
>>> Molto meglio IMHO 'partire' con una serie di utility OS...
>> OK. Qualche idea ? Per quale OS ?
> Il nome del newsgroup non ti suggersice nulla??? :-))
Fuori le idee !!
>>>>> Mah. Fare un gestionale user-oriented pare brutto???
>>> Se non ci arrivi, e' inutile spiegartelo
sviluppo ad oggetti lasciamola ai fighetti, alle cose serie ci pensiamo noi
uomini veri, sotto con la tastiera e pedalare"?
pacchetto, pensiamo a fare un pacchetto che sia buono per gli utenti
(e, come ha detto gabriele, che funzioni). Poi, possiamo anche
scriverlo in Assembly, ma e' un fatto collaterale.
L' OO, cosi' come altre nuove tecniche, nasce anche (ma non solo) per risolvere una serie di problemi che si "scaricano" direttamente sugli utenti. Se, per esempio, parliamo di "software che funzioni" tocchiamo uno degli argomenti principali che ha condotto alla formalizzazione di tecniche per il "software reuse", di cui l'OO e', allo stato attuale, la migliore soluzione per quanto riguarda la fase di "scrittura" del codice.
Io, assieme ad altri colleghi/collaboratori, sto sperimentando da anni la validita' e l'efficacia dell'impiego di "standard" di programmazione RPG utilizzati in maniera estensiva. Otteniamo ottimi risultati per quanto riguarda la rapidita' di sviluppo, la facilita' di manutenzione, l'uniformita' dell'interfaccia utente ed altro. Mi sto pero' rendendo conto che con l'OO sarebbe possibile fare molto di piu'.
La qualita' del software, anche per la parte che l'utente puo' apprezzare dal suo punto di vista, dipende in larga misura proprio dal *come* il software e' progettato e "scritto", soprattutto quando si tratta di progetti di grosse dimensioni quali sono quelle di un pacchetto gestionale anche modesto.
Purtroppo, a fronte di una bibliografia ormai imponente al riguardo (di produzione principalmente USA), mi rendo conto, ad esempio sfogliando i cataloghi degli editori specializzati, che in Italia il grado di sensibilita' per questi temi ed il relativo dibattito sono ancora ad un livello "embrionale".
A tutti voi ...
auguri di Buon Natale e di un Felice Anno Nuovo e ...
buon Millenium Bug !!
Mumix
Piero Cavina
> Chiunque sia il tuo *utente* di riferimentio credo che sarebbe *molto*
> contento di avere come risposta alle sue richieste software che:
> - "arriva" prima
> - e' molto piu' affidabile in quanto contiene meno errori (quindi
*funziona*
> meglio)
> - viene corretto e implementato piu' velocemente
> - costa meno
Mettendola in altri termini, se una diversa metodologia di sviluppo del sw
risulta complessivamente più economica, allora a parità di risorse si può
dare di più agli utenti.
> Per quanto riguarda poi l'interfaccia utente (che e' una delle cose piu'
> dispendiose in termini di tempo durante la fase di sviluppo) credo che la
> sua qualita' principale dovrebbe essere la "coerenza".
Sarebbe ora che qualsiasi progetto di un certo respiro contemplasse una
figura specializzata nella progettazione e verifica della sola interfaccia
utente e del dialogo con l'utente - anche nel caso di una UI lineare come
quella dell'AS400. Vi segnalo sull'argomento questo eccellente sito:
http://www.iarchitect.com/mshame.htm
che è pure molto divertente.
Tornando all'OOD/OOP, temo che il problema principale sia essenzialmente la
mole di nozioni e esperienze nuove che generazioni di analisti e
programmatori cresciuti sul modello procedurale dovrebbero acquisire. Non è
vero che per programmare ad oggetti bisogna dimenticarsi tutto (quando vai
ad implementare un metodo si tratta sempre di classica programmazione
procedurale) ma di cambiare completamente l'approccio alla soluzione dei
problemi. Non è chiaro se, e in quanto tempo, questo processo di
cresita-conversione del personale sarà possibile. E' anche vero che dovremmo
essere entrati nell'era della "formazione permanente", no? ;-)
Mauro Mariz
> essere entrati nell'era della "formazione permanente", no? ;-)
certo, sicuramente da quando c'è l'AS/400...
bye
Mauro Mariz
3nto
Un Mauro che con il S/34 una volta che avevi letto una decina di manuali
conoscevi tutto quello che c'era da sapere...