L'azienda vuole che usiamo l'impegno o forniamo uno SLA [chiuso]

Full disclosure - Sono stato dal lato esigente di una richiesta di escrow, quindi per favore perdonami per qualsiasi pregiudizio evidente.

Organizzazioni di grandi dimensioni come google e utility generalmente non modificano frequentemente le applicazioni software. Non è raro che un'applicazione viva da 10 a 15 anni, con solo pochi aggiornamenti di versione. Possono prendere "sudare le risorse" in una forma d'arte ... Le nuove applicazioni rappresentano un grande investimento di risorse al fine di portare e mettere a frutto. Cambiare applicazioni significa buttare via quell'investimento precedente.

Uno dei maggiori rischi per loro nella valutazione del nuovo software è la stima della probabilità che il venditore sarà in attività nei prossimi tre, cinque, dieci anni e così via. Il requisito di escrow consente loro un'opzione di fallback se la loro amata applicazione non è più disponibile nella sua forma preferita.

Le acquisizioni possono significare la morte di un prodotto mentre lo acquistano. La prospettiva del tuo futuro cliente potrebbe essere quella di equiparare l'acquisizione alla morte. Se sono stati bruciati una volta prima, allora è probabile che lo vedano. OTOH, onestamente non lo vedo come una grande pillola avvelenata per una società acquirente. I loro diritti sul software saranno limitati al solo client. Non possono girarsi e fornire lo stesso servizio agli altri con il codice che hanno ricevuto tramite l'impegno.

La clausola SLA è un po 'nuova dal mio punto di vista, ma penso che sia dovuta al modello SaaS che offri.

Una volta applicato un punto di vista "paura della perdita", puoi capire perché hanno chiesto l'impegno. E ti dà anche la chiave per trovare una soluzione gradevole. Sul rovescio della medaglia, significa che vogliono usare il tuo software e saranno probabilmente i clienti per molto tempo. Le grandi organizzazioni non acquistano software solo per risatine.

Avere un flusso costante di clienti a basso rischio di fuga può essere molto attraente per una società acquirente, specialmente se intendono continuare o migliorare il servizio. Anche se il client ha una copia del vecchio codice, continuerà con la nuova versione se soddisfa le sue esigenze.

Le richieste e le reazioni iniziali sono sempre irragionevoli. :-) Penso che tu possa trovare una soluzione salutare.

Il mio consiglio per te ... prendi un avvocato. Stai giocando con i grandi ora, chiedendo a un gruppo di estranei in un Q & A un sito qualcosa di così importante per la tua azienda non è il modo giusto per farlo.

Un Contratto di servizio (SLA) non implica una commissione di servizio mensile o annuale. Un SLA stabilisce un accordo su cose come uptime, prestazioni, disponibilità dei dati, notifiche di tempi di inattività, tempi di risposta del supporto e altre cose di tale natura. Uno SLA con "requisiti veramente elevati" potrebbe specificare che il servizio deve essere disponibile il 99,999% delle volte e specificare i tempi di risposta per varie operazioni. Ad esempio, se il venditore deve effettuare una serie di chiamate di servizi Web, potrebbe volere assicurarsi che, ad esempio, il 99% delle chiamate ritorni in < 0,5 secondi. E lo SLA in generale specifica sanzioni per il fornitore di servizi se questi obiettivi non sono soddisfatti - generalmente, ciò implicherebbe la riduzione o l'eliminazione delle commissioni pagate dal consumatore del servizio al fornitore di servizi ma si potrebbe strutturare lo SLA per coinvolgere il rilascio del codice depositato. se il provider è costantemente in grado di soddisfare gli obiettivi.

Ovviamente, vorrai assicurarti che gli obiettivi siano sufficientemente conservativi che non ci sarebbe alcun rischio reale di violarli fino a quando il servizio è stato attivamente curato (da te o da chiunque abbia acquistato l'azienda). Ma consentirebbe il rilascio del codice depositato se la tua azienda non fosse fallita, ma semplicemente smesso di fornire supporto e monitoraggio attivi e lasciare che il servizio scendesse regolarmente.

In primo luogo, SLA è il termine per fornire un servizio a un livello definito, può includere sia sanzioni e premi, cessazione di accordi e impegno per un più alto livello di utilizzo. In pratica qualsiasi cosa tu possa pensare di mettere in un contratto, con termini che dipendono dai livelli di servizio (tempo di attività, numero di visitatori, tempo di risposta, tassi di fallimento, ecc.).

In secondo luogo, i governi non corrotti non sono interessati a rubare il tuo codice, sono interessati a preservare il loro investimento. Supponendo un governo non corrotto, stanno semplicemente riducendo il rischio. Organizzazioni più grandi di qualsiasi tipo si preoccupano più del costo dei tempi di inattività e delle modifiche rispetto alle piccole imprese, perché sono più costose per una grande organizzazione - proprio come un semplice esempio considerando che l'utilizzo del servizio è probabilmente al costo di diverse migliaia di dollari al minimo assoluto, potrebbe facilmente essere decine di migliaia; riunioni, valutazioni tecniche, appunti, ecc ...

Fondamentalmente una grande organizzazione sarà interessata a due cose: cosa succede se il tuo servizio cambia in un modo che lo rende inutilizzabile, e cosa succede se il tuo servizio diventa semplicemente non disponibile. Per rendere il tuo servizio attactive a loro, concentrati sulle soluzioni a questi problemi, non sul fatto che se vai fuori mercato non devi pagarti più - non pagarti è esattamente ciò di cui sono preoccupati.

Quindi, un conto di deposito a garanzia (o anche il rilascio automatico della versione attuale o precedente) con un contratto chiaro che specifica di mantenere la proprietà in tutte le condizioni e una clausola di non concorrenza che dice che non possono offrire il servizio a nessuno altrimenti in qualsiasi circostanza e può farlo solo per i propri clienti / utenti nel caso in cui non si rispetti il livello specificato di servizio.

In realtà puoi usare questo come un punto di forza, possibilmente includendo l'uso dei loro computer come server "fall over" (le versioni di codice attuali / precedenti possono significare che i loro programmatori / tecnici sono sempre pronti a fare un passaggio, cadere sui server potrebbe significare zero tempo di inattività nel caso in cui si stacca la spina). Non dimenticare di includere sanzioni se rilasciano il tuo codice a causa di un errore o di un dipendente disonesto.

Onestamente, questa sembra una grande opportunità.