<HTML>
<HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="OPENWEBMAIL" name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<font size="2"><b>On Sat, 9 Apr 2011 12:09:33 +0200, G. Allegri wrote</b>
<br />> Ho un caro amico che aveva un progetto Gvsig
articolato, che gli è
<br />> andato bene per tre anni. Vuole aggiornare il sw, ma per
riottenere
<br />> lo stesso progetto ha dovuto pagare un professionista per farsi
ricostruire
<br />> il progetto perché non riusciva più ad aprirlo con la versione
aggiornata.
<br />> Un altro collega aveva un sito con Ka-Map. Il progetto è praticamente
<br />> abbandonato. Vuole sfruttare alcune funzionalità presenti in sw più aggiornato,
<br />> e per farlo o si fa sviluppare gli aggiornamenti per Ka-Map o si rifà la sua
<br />> architettura con altri
strumenti. Questi due esempi sono quasi banali.
<br />> Ma era per dartene alcuni semplici
semplici,
<br />> per dirti cosa intendo per lock-in ambito open...
<br />> Credo che
siano questioni inevitabili. QGis 2.0 non supporterà più le API
<br />> date per
deprecate. Chi avrà sviluppato le proprie applicazioni su quelle API,
<br />> dovrà
riscriversele se vuole usare il nuovo
QGis.
<br />>
<br />
<br />scusa Giovanni, ma che c'entra tutto questo con il lock-in ?
<br />sicuramente sono "infortuni" spiacevoli legati ad un cambio di
<br />versione: che possibilmente andrebbero evitati e/o mitigati.
<br />
<br />ma di sicuro nessuna di queste situazioni può essere definita
<br />come lock-in.
<br />il lock-in consiste nella deliberata introduzione di ostacoli
<br />pseudo-tecnologici tali da costringerti a rimanere eternamente
<br />legato ad un determinato prodotto una volta che hai iniziato
<br />ad utilizzarlo.
<br />[implicitamente, non ha senso parlare di lock-in in abito
<br />sw libero, visto che ovviamente tutto è aperto, trasparente,
<br />standard e documentato ... e soprattutto non ci sono di
<br />sicuro oscuri interessi commerciali da tutelare più o
<br />meno disinvoltamente]
<br />
<br />qua nel caso sia di gvSIG che di QGIS casomai avviene
<br />esattamente il contrario: quando scopri che la nuova
<br />versione aggiornata ti crea problemi, magari inizi a
<br />guardarti intorno e decidi di passare a qualcos'altro.
<br />dov'è finito il subdolo tentativo di legarti indissolubilmente
<br />al brand ?
<br />
<br />il caso Ka-Map poi è ancora un'altra storia: dove lo
<br />vedi il lock-in se un progetto si ferma e non va avanti ?
<br />non dubito che la situazione sia spiacevole per chi
<br />ci si trova nel mezzo: ma di sicuro non è lock-in
<br />
<br />
<br />> Succede nel proprietario. Succede in ambito Open.
<br />> Ovvio, in
quello Open chiunque può farlo perché ha libero accesso al codice.
<br />> Ma in
pratica, quanti sono capaci di farlo?
<br />>
<br />
<br />Scusa del poco ... hai detto un prospero :D
<br />- col sw libero sicuramente potrai sempre e comunque recuperare
<br /> i tuoi dati grezzi in un qualche formato standard e facilmente
<br /> riutilizzabile su altre piattaforme (ed i dati grezzi rappresentano
<br /> comunque il tuo patrimonio reale).
<br />- e potrai facilmente trovare consulenti e sviluppatori a gogo
<br /> che possono eventualmente darti una mano per 'ammorbidirti'
<br /> una migrazione eventualmente difficoltosa ... con spesa
<br /> sicuramente non confrontabile con quella dei canoni
<br /> di licenza di qualsiasi sw proprietario a tua scelta.
<br />
<br />Facciamoci due conti spicci: prendiamo il caso del tuo amico che
<br />ha dovuto pagare un consulente per rattoppare gvSIG al cambio
<br />di versione:
<br />- quanto ci ha speso ?
<br />- e quanto ha risparmiato rispetto all'acquisto di enne licenze d'uso
<br /> e dei relativi canoni di manutenzione per altri enne anni ?
<br />siamo proprio sicuri che nel complesso è andato in perdita secca ?
<br />
<br />ciao Sandro
<br />
</font>
</BODY>
</HTML>