È una cattiva pratica smettere di fornire supporto per software obsoleti se gli aggiornamenti sono gratuiti e facili?

Se imposti il problema nel modo in cui lo fai affermando esplicitamente che non ci sono motivi validi per non aggiornare, tutti concorderanno sul fatto che non ci sono motivi per supportare versioni precedenti. Eliminare motivi legacy per non aggiornare, tuttavia, è molto più facile a dirsi che a farsi.

La nuova versione apporta modifiche all'interfaccia utente? In tal caso, ciò potrebbe significare che le schermate e le registrazioni dello schermo che un'azienda ha messo insieme per mostrare agli utenti come eseguire un particolare compito devono essere riscritte. Ciò potrebbe significare che gli utenti devono passare un po 'di tempo ad adeguarsi alla nuova interfaccia utente per fare le stesse cose che hanno sempre fatto.

Puoi davvero garantire che gli aggiornamenti siano privi di rischi? Si utilizza l'esempio del programma di installazione di SQL Server 2008 SP2 che rende il server inutilizzabile. Microsoft ha speso molto più tempo e denaro testando il programma di installazione SP2 di quanto la maggior parte delle aziende possa permettersi di testare ogni possibile configurazione che potrebbe influire sull'installatore. SQL Server è un prodotto aziendale, quindi, in genere, c'è una minore variabilità in ciò che le persone hanno installato sui loro server rispetto a quando si guardano le scatole dei consumatori. E c'è un sacco di tempo tra i service pack di SQL Server quindi non c'è fretta di far uscire il software. Eppure, nel tuo esempio, Microsoft non ha ancora consegnato. Ciò dovrebbe dimostrare quanto sia difficile spedire un upgrade privo di rischi al 100% anche se tutto si schiera a tuo favore. E anche se potessi offrire un upgrade completamente privo di rischi al 100%, come fa il tuo cliente a sapere che i tuoi aggiornamenti, a differenza di ogni altro aggiornamento che devono affrontare, sono privi di rischio?

La nuova versione apporta modifiche alle funzionalità esistenti? Anche se stai solo correggendo un bug, una volta che hai abbastanza clienti, è probabile che qualcuno da qualche parte dipenderà da quel comportamento bug. Pensa a tutti i siti, ad esempio, che sono stati ottimizzati per alcune versioni di alcuni browser che non funzionano o sembrano terribili quando vengono corretti i bug nella gestione del vecchio browser di alcuni elementi HTML.

Se riconosci che esistono validi motivi legacy per non eseguire l'upgrade, sei ben consapevole dei tuoi diritti a prendere una decisione politica che la facilità di manutenzione e il supporto snellimento superino le esigenze legacy dei clienti. Indipendentemente dal fatto che questa sia la decisione giusta, dipenderà da quanto siano grandi i problemi legacy e quanto sia costoso sostenere le vecchie versioni. Ma hai molta più probabilità di fare il giusto compromesso se affronti il problema ipotizzando che ci siano molte fonti di problemi legacy legittimi e capendo come quantificare tali problemi se non partendo dal presupposto che non ci sono legacy problemi.

Potresti voler supportare le versioni n-2 e n-1 (o solo n-1) insieme alla versione n dove n è la versione corrente, solo per dare alle persone un po 'di tempo per l'aggiornamento. Ma non puoi sostenere qualcosa per sempre - non è solo realistico.

Penso che dipenda in gran parte da come viene utilizzato il tuo software. Se c'è la possibilità che un utente incorporerà il tuo software in un sistema automatizzato, sia esso un chiosco, uno script di compilazione, un server remoto, ecc., Allora è probabile che questi tipi di utenti saranno resistenti all'aggiornamento, non importa quanto "gratuito" e "facile" potrebbe sembrare allo sviluppatore.

Il problema è che una volta che il software è trincerato in un sistema mission-critical [1], il rischio di eventuali modifiche a una parte di quel sistema aumenta rapidamente. Qualsiasi cambiamento ha la possibilità di rompere qualcosa che significa che "libero" non è più gratuito.

La domanda originale cerca di escludere questo tipo di problema "legacy" o "sicurezza", ma farlo richiede un grande passo in avanti in termini di previsione del modo in cui il software sarà effettivamente utilizzato. Basta guardare al numero di strani bug di Windows che vengono mantenuti perché vari programmi sono diventati dipendenti dal comportamento specifico per capire che l'uso del mondo reale non è sempre l'utilizzo come progettato.

Detto questo, probabilmente si tratta di una decisione aziendale più che di una programmazione, salvo la perdita di informazioni critiche, risorse o codice. Il vantaggio finanziario di fornire o essere in grado di fornire supporto per una versione obsoleta supera il costo della capacità di fornire tale supporto?

[1]: come definito dall'utente

Personalmente ritengo che sia necessario annunciare, in anticipo (almeno un anno, ma tre è meglio) che interromperete il supporto. Sarebbe anche bello dire, con la versione del software in vendita, quale sia l'orizzonte di supporto previsto. Unbuntu è così.

Penso che quello che stai cercando qui è un processo di rilascio e supporto appropriato .

Ovviamente, tutto ciò deve essere definito in base ai tuoi obiettivi e al tuo mercato (ad es. Consumer vs Enterprise).

Prima di tutto sarebbe necessario impostare un Ciclo di vita del prodotto appropriato per il software rilasciato. Ad esempio potresti voler avere fasi come:

1. Generalmente disponibile - In grado di essere acquistato, commercializzato attivamente, supportato.
2. Fine del marketing : disponibile su richiesta, supportato
3. Fine vita - Non più disponibile, non più supportato (eccetto casi eccezionali)

Dovrai avere un processo noto in cui spostando un prodotto da uno stadio all'altro è annunciato un certo periodo di tempo in anticipo . In alcuni casi e in base ai contratti, questo sarebbe un requisito legale.

Come sottolineato da La risposta di Scott dove per versione n è GA, n-1 è EOM e n-2 è EOL. Regola questa situazione (ad esempio, più versioni precedenti sono ancora solo in EOM).

Da qui, probabilmente vorrai impostare una forma di accordo di manutenzione in corso . Vale a dire, dopo che qualcuno acquista un prodotto, sono supportati per il periodo 'x'. Per rimanere supportati devono pagare una quota in corso. Esistono diverse strategie su come gestire questa tassa e gli aggiornamenti del prodotto, tra cui:

1. Costo di manutenzione costante (ad esempio% del prezzo originale)
2. Costo di manutenzione costante fino al periodo 'y' dopo un nuovo rilascio, quindi aumento di 'z'% ogni periodo
3. Aggiornamenti gratuiti
4. Aggiornamenti scontati
5. Aggiornamenti a prezzo pieno

Ci sono molti vantaggi in questo per te. In primo luogo, ti dà un flusso di entrate in corso che aiuta a pagare per il supporto. In secondo luogo, può incoraggiare gli utenti a eseguire l'aggiornamento a versioni più recenti.

In definitiva, dipende molto dalla tua situazione, ma è quasi sempre universalmente vero che dovresti

1. Avere un piano in atto
2. Assicurati che i tuoi clienti siano a conoscenza del piano
3. Avere nei contratti
4. Segui il piano

Per non essere accusato di cattive pratiche.

La sua non è una cattiva pratica, no. Per il mio software, faccio solo 'correzioni' per la versione corrente. Aiuterò un utente di una versione precedente se c'è un work-around. Ma non voglio apportare modifiche al codice. Nel peggiore dei casi, darò all'utente un aggiornamento alla nuova versione.

Ma in realtà dipende dalla natura del tuo software e da quali promesse / contratti di supporto hai. Supportare solo la versione corrente potrebbe non essere accettabile per alcuni software utilizzati dalle organizzazioni. Ma per il software di fascia consumer, va bene.

Quando si parla di software libero (Chrome), la sua non è una pratica negativa. Stanno facendo un favore all'utente offrendo il software gratuitamente. Non devono nulla all'utilizzatore finale.

Per essere onesto con te, ho pensato a 10 minuti e non ho riscontrato alcun problema con l'interruzione del supporto per versioni obsolete e la richiesta di aggiornamento da parte degli utenti . È semplicemente logico avere un problema con. Voglio dire, la nuova versione è gratuita e cosa c'è di meglio che usare qualcosa gratuito ?

Questo dipende molto dalla circostanza. Penso che puoi usare il buon senso per decidere quando ha senso.

Nella maggior parte dei casi, direi che dare il supporto di versioni precedenti per un anno sarebbe appropriato, a patto che ci si assicuri che il cliente lo capisca.

Direi anche che dovresti fornire supporto completo per il processo di upgrade da una versione fino a 5 anni o più.

Ie. dovresti supportare le vecchie versioni abbastanza per essere in grado di aggiornarle a una versione che puoi supportare. Se non è possibile supportare l'aggiornamento, è necessario supportare la versione precedente.