faretesto > lavoro.* > lavoro.informatica

Marcus (12.10.2017, 00:25)
Salve a tutti,

suppongo di non chiedere qualcosa di nuovo o eccezionale e vorrei capire
qual'è la best practice in merito.
Supponiamo che io erogo un servizio in cloud, il cliente medio si
abbona, paga i suoi xx euro/mese per il servizio ed in genere è contento
così, senza che debba porti questioni tecniche sul servizio.

Poi arriva il cliente più grosso e strutturato, il quale però si
convince a rimanere in cloud da te, però contrattualmente gli eroghi il
servizio su risorse dedicate e fin qui benone.

Poi arriva il cliente ancora più grosso che inizia a romperti le balle
col fatto che vuole il servizio ma vuole erogarlo Onsite.
Tu gli dici che va bene, invece di un canone mensile ci sarà una diversa
offerta economica + contratto di supporto ed aggiornamento; senza che
questo preveda il rilascio dei sorgenti.
Il cliente però ti rompe le balle (forse giustamente) perchè si pone il
problema che se tu tra un anno te ne vai ai caraibi, loro rimangono con
un oggetto inservibile che non possono sviluppare.

Ok, in questa situazione, NON volendo rilasciare i codici sorgente anche
dietro firma di un accordo blindato, è una opzione percorribile quella
di depositare periodicamente i codici sorgente presso terzi?
Diciamo non so un avvocato esperto in questioni software che dietro
compenso annuo si fa garante del fatto che se io domani scompaio, il
cliente può andar li a reclamare i sorgenti.
Il cliente pagherà una fee annua addizionale per servizio e potremmo
essere tutti contenti.

Che ne dite?
Infradito (12.10.2017, 08:33)
>Ok, in questa situazione, NON volendo rilasciare i codici sorgente anche
>dietro firma di un accordo blindato, è una opzione percorribile quella di
>depositare periodicamente i codici sorgente presso terzi?
>Diciamo non so un avvocato esperto in questioni software che dietro
>compenso annuo si fa garante del fatto che se io domani scompaio, il
>cliente può andar li a reclamare i sorgenti.


A me e' capitato esattamente cosi'. Deposito dal notaio, con la clausola che
il notaio non puo' aprire il plico fino a quando l'azienda e' in essere.
Marcus (12.10.2017, 09:41)
Il 12/10/2017 07:33, Infradito ha scritto:
> A me e' capitato esattamente cosi'. Deposito dal notaio, con la clausola
> che il notaio non puo' aprire il plico fino a quando l'azienda e' in
> essere.


Bene, posso chiederti due info?

Con gli aggiornamenti quale era l'accordo? Cioè suppongo non fosse un
blocco monolitico immutabile. Deposito dal notaio ogni x mesi?

Spannometricamente il costo annuo dell'operazione per il cliente?

Grazie mille!
Roberto Tempesti (12.10.2017, 09:42)
Il 12/10/2017 07:33, Infradito ha scritto:
> A me e' capitato esattamente cosi'. Deposito dal notaio, con la clausola
> che il notaio non puo' aprire il plico fino a quando l'azienda e' in
> essere.


Teoricamente e' perfetto, ma nella pratica?...se rilasci, diciamo, 3 fix
al mese e due release l'anno cosa fai? apri e chiudi il plico continuamente?
Altro metodo potrebbe essere depositare i sources sulle macchine dei
clienti in modalita' criptata e le chiavi, quelle si, depositate presso
un notaio eccetera eccetera....
Saluti
infradito (12.10.2017, 11:16)
Il 12/10/2017 08:42, Roberto Tempesti ha scritto:
> Il 12/10/2017 07:33, Infradito ha scritto:
> Teoricamente e' perfetto, ma nella pratica?...se rilasci, diciamo, 3 fix
> al mese e due release l'anno cosa fai? apri e chiudi il plico
> continuamente?
> Altro metodo potrebbe essere depositare i sources sulle macchine dei
> clienti in modalita' criptata e le chiavi, quelle si, depositate presso
> un notaio eccetera eccetera....
> Saluti


Rispondo a entrambi.
Nella pratica non serve a un cazzo, ovviamente.
I sorgenti sono li da tempo e non sono stati mai aggiornati perche'
questo ha un costo (che pero', per rispondere a Marcus, non conosco. Si
e' occupato di tutto il cliente). Magari tra un po' si fara' un refresh
del deposito.
E' una sicurezza per il cliente, poi praticamente non serve a molto. Su
progetti di questo tipo solo per capire come funziona dal sorgente ci
vorrebbero mesi o anni.
Roberto Tempesti (12.10.2017, 11:23)
Il 12/10/2017 10:16, infradito ha scritto:
> E' una sicurezza per il cliente, poi praticamente non serve a molto. Su
> progetti di questo tipo solo per capire come funziona dal sorgente ci
> vorrebbero mesi o anni.


Su questo quoto senza riserve.
FP (12.10.2017, 16:04)
Azzardo una risposta: utenza github "professionale", quindi con accesso
username-password e/o con certificato, depositati in copia dal notaio.

In questo modo il codice è sempre aggiornato. Eventualmente non è il
repository di sviluppo ma ci confluisce solo un'unica patch cumulativa
ad ogni rilascio.
rootkit (12.10.2017, 17:44)
Il Wed, 11 Oct 2017 23:25:40 +0200, Marcus ha scritto:

> Poi arriva il cliente ancora più grosso che inizia a romperti le balle
> col fatto che vuole il servizio ma vuole erogarlo Onsite.
> Tu gli dici che va bene, invece di un canone mensile ci sarà una diversa
> offerta economica + contratto di supporto ed aggiornamento; senza che
> questo preveda il rilascio dei sorgenti.
> Il cliente però ti rompe le balle (forse giustamente) perchè si pone il
> problema che se tu tra un anno te ne vai ai caraibi, loro rimangono con
> un oggetto inservibile che non possono sviluppare.


scusa, per capire: perché "inservibile"?
considerato che ce l'avrebbero in casa, diventa *davvero* inservibile nel
momento in cui, per qualsiasi ragione, viene meno il supporto?
rootkit (12.10.2017, 19:28)
Il Thu, 12 Oct 2017 10:16:56 +0200, infradito ha scritto:

> E' una sicurezza per il cliente,


bah.

a me sembra più una logica del tipo: faccio prima a metterglielo nel culo
che nel capo.
solo per fare un esempio: se tu domattina decidessi di abbandonare quel
software perchè fatti due conti vedi che non ti conviene (cosa che è
nelle tue facoltà di imprenditore), che deve aspettare che tu chiuda la
società per avere tutela?
Dr.UgoGagliardelli (12.10.2017, 19:34)
Il 12.10.2017 16.44, rootkit ha scritto:
> Il Wed, 11 Oct 2017 23:25:40 +0200, Marcus ha scritto:
> scusa, per capire: perché "inservibile"?
> considerato che ce l'avrebbero in casa, diventa *davvero* inservibile nel
> momento in cui, per qualsiasi ragione, viene meno il supporto?

Magari al pagamento del canone viene rilasciata una chiave di
attivazione senza la quale il software diventa appunto "inservibile".
rootkit (12.10.2017, 20:57)
Il Thu, 12 Oct 2017 18:34:39 +0200, Dr.UgoGagliardelli ha scritto:

> Magari al pagamento del canone viene rilasciata una chiave di
> attivazione senza la quale il software diventa appunto "inservibile".


in tal caso basterebbe rilasciargli una chiave permanente. senza stare ad
inventarsi chissà quale soluzione complicata.
Marcus (12.10.2017, 22:30)
Il 12/10/2017 16:44, rootkit ha scritto:
> Il Wed, 11 Oct 2017 23:25:40 +0200, Marcus ha scritto:
> scusa, per capire: perché "inservibile"?
> considerato che ce l'avrebbero in casa, diventa *davvero* inservibile nel
> momento in cui, per qualsiasi ragione, viene meno il supporto?


Beh, oddio posto che non smetterebbe di funzionare il giorno dopo e
posto che non vi siano strumenti di licenza da essere rinnovati, tu come
azienda potresti affidarti ad un software non più manutenuto di cui non
hai i sorgenti?

Come minimo dovrebbero usare il tempo che il sistema ancora funziona per
migrare altrove, almeno nella mia opinione.
rootkit (13.10.2017, 08:55)
Il Thu, 12 Oct 2017 21:30:13 +0200, Marcus ha scritto:

> Il 12/10/2017 16:44, rootkit ha scritto:
> Beh, oddio posto che non smetterebbe di funzionare il giorno dopo e
> posto che non vi siano strumenti di licenza da essere rinnovati, tu come
> azienda potresti affidarti ad un software non più manutenuto di cui non
> hai i sorgenti?


messa così certo che no. ma se giudicassi sin da ora concreta
l'eventualità che tu mi lasci a piedi non prenderei proprio in
considerazione il tuo software, frega niente dei sorgenti.

immagino che se fai un contratto di supporto tu abbia, allo stato
attuale, mezzi ragionevolmente dimostrabili per onorarlo. questo è imho
quanto basta e quanto deve bastare; non capisco perché il cliente grosso
in quanto grosso abbia la pretesa di vedersi garantita la disponibilità
vita natural durante, mentre loro ovviamente possono decidere ad ogni
scadenza se rinnovare o no.

> Come minimo dovrebbero usare il tempo che il sistema ancora funziona per
> migrare altrove, almeno nella mia opinione.


giusto, e non è la stessa cosa che hanno accettato quando hanno comprato
(ad esempio) windows xp?
Dr.UgoGagliardelli (13.10.2017, 09:14)
Il 12.10.2017 19.57, rootkit ha scritto:
> Il Thu, 12 Oct 2017 18:34:39 +0200, Dr.UgoGagliardelli ha scritto:
> in tal caso basterebbe rilasciargli una chiave permanente. senza stare ad
> inventarsi chissà quale soluzione complicata.

In genere, chi pratica questa politica, non sono pochi, rilascia chiavi
temporanee per assicurarsi il pagamento dei canoni ricorrenti.
Sei libero di chiamarlo ricatto, se vuoi. :-)
menegotto.luca (13.10.2017, 10:15)
Il giorno venerdì 13 ottobre 2017 07:55:47 UTC+2, rootkit ha scritto:

> messa così certo che no. ma se giudicassi sin da ora concreta
> l'eventualità che tu mi lasci a piedi non prenderei proprio in
> considerazione il tuo software, frega niente dei sorgenti.


Ecco. Credo questo sia il busillis.
Lo confesso: io, i sorgenti, li ho sempre lasciati presso il cliente. Li, belli in vista e disponibili - se poi i sorgenti sono in Python o Ruby, allora il problema manco si pone.
Resto dell'idea che ciò che conta del software non siano i sorgenti, sia l'idea e la conoscenza che stanno dietro i sorgenti, e il servizio che io do nel tempo alla loro manutenzione ed evoluzione.
La dimostrazione che do è personale e limitata, me ne rendo conto. Però TUTTI i clienti che ho - tranne uno, con cui ho baruffato a fuoco - quando hanno esigenze nuove, chiamano me. D'altra parte, dare a un qualcunoche non l'ha mai visto un pacco di qualche decina di migliaia di righe di codice (è un progetto che sto revisionando proprio adesso) senza che il tapino abbia almeno una vaga idea dei perché e percome, è un salto nel buio economicamente molto pericoloso e senza garanzia di successo.

Discussioni simili