Hai bisogno di consigli sull'implementazione di una prova a tempo limitato

Question

Sto sviluppando un'applicazione desktop shareware. Sono al punto in cui devo implementare il codice di prova / uso / attivazione. Come ti avvicini a qualcosa del genere? Ho le mie idee, ma voglio vedere cosa pensa la community di StackOverflow.

Sto sviluppando con C ++ / Qt. La piattaforma prevista è Windows / Mac / Linux.

Grazie per il tuo consiglio!

Answer 1

Cosa proteggere e cosa non proteggere:

Tieni presente che le persone troveranno sempre un modo per aggirare il periodo di prova. Quindi vuoi rendere fastidioso per la persona dover superare il periodo di prova, ma non importa se è impossibile aggirare il periodo di prova.

La maggior parte delle persone penserà che sia troppo lavoro per tentare di aggirare il periodo di prova se esiste anche un meccanismo semplice. Ad esempio, le persone possono sempre utilizzare filemon / regmon per vedere quali file e voci di registro cambiano durante l'installazione del software.

Detto questo, un meccanismo semplice è il migliore, perché ti fa perdere meno tempo.

Ecco alcune idee:

• Puoi fare un conteggio dei tick da qualche parte nel registro per ogni singolo giorno che viene eseguito. Se il segno di spunta conta > 30 quindi mostrare loro un messaggio scaduto.
• Puoi archiviare la data di installazione, ma fai attenzione a controllare se hanno più giorni disponibili di quelli previsti dal tuo periodo di prova, quindi informali che sono scaduti. Questo proteggerà dalle persone che cambiano la loro data prima dell'installazione in un giorno futuro.
• Ti consiglierei di effettuare la disinstallazione, rimuovere i tuoi " giorni consecutivi " contare. Questo perché le persone potrebbero rivalutare il tuo prodotto mesi dopo e eventualmente acquistarlo. Ma se non riescono a valutarlo, non compreranno. Nessun utente serio avrebbe il tempo di disinstallare / reinstallare solo per ottenere un ulteriore utilizzo del prodotto.

Estensione delle prove:

Per noi, quando un cliente richiede un'estensione di prova, inviamo loro un'e-mail automatica che contiene un programma "TrialExtend.exe" e un codice di estensione di prova. Questo programma contatta il nostro server con il codice di estensione di prova per convalidarlo. Se il codice viene convalidato, il periodo di prova viene ripristinato.

Answer 2

Qualunque cosa tu faccia, tieni d'occhio la data del sistema. Il trucco più antico del libro è installare un'applicazione ad un certo punto in futuro e poi tornare alla data reale una volta che l'applicazione ha memorizzato la data stupida al primo avvio. Forse sincronizzare la chiave con un repository online?

Answer 3

La risposta di Brian è fantastica, ma vorrei aggiungere qualcosa.

Gli utenti Linux generalmente non sono abituati a pagare per il software e tendono ad essere più esperti di tecnologia e forse anche "religiosi" su questioni open source.

Per questo motivo, consiglierei davvero di mantenerlo semplice: è davvero solo una piccola barriera per rendere l'acquisto del software almeno facile come rubarlo.

Suggerirei che tormenta o disabilita alcune funzionalità (ad esempio il salvataggio) dopo il periodo di prova piuttosto che morire completamente. Solo un'osservazione, ma le restrizioni basate sulle funzionalità sembrano più comuni nel mondo di Linux.

A parte questo, rendere la versione di Linux una "prima classe" versione: un buon programma di installazione, ecc. aiuterà.

Se sei relativamente piccolo, o il tuo programma è relativamente di nicchia, c'è una piccola possibilità che qualcuno si preoccupi di romperlo, quindi concentrati solo sulla creazione di un buon prodotto con un nervosismo diretto una volta scaduto il tempo.

Answer 4

Se è [abbastanza] probabile che tu abbia una connessione di rete, puoi fare in modo che il programma di installazione si registri con il tuo sito Web, quindi verifica contro di esso ogni volta che si avvia.

Se ciò non è possibile, può essere utile scrivere un valore in un punto modificabile dal mondo sul filesystem (una voce di registro, una voce nel file di configurazione e / etc / etc, ecc.)

Answer 5

Forse il vero problema è la prova a tempo limitato. La società per cui lavoro fa molto lavoro su Active Directory e di solito limitiamo il nostro software a un numero limitato di utenti per le versioni di prova. Ritengo che limitare la funzionalità in qualche modo sia a volte migliore, più facile da implementare e non fallisca quando l'utente cambia semplicemente la data sul proprio computer.
Vi è un atto di bilanciamento in quanto non è possibile limitare la funzionalità troppo rigorosamente, altrimenti gli utenti non ottengono nulla dalla versione di prova. Allo stesso tempo, un limite troppo allentato non incentiva l'acquisto.