Besoin de conseils sur la mise en œuvre d'un essai limité dans le temps

Question

Je développe une application de bureau shareware. Je suis sur le point d’implémenter le code d’utilisation / d’activation. Comment abordez-vous quelque chose comme ça? J'ai mes propres idées, mais je veux voir ce que pense la communauté du stackoverflow.

Je développe avec C ++ / Qt. La plate-forme prévue est Windows / Mac / Linux.

Merci pour vos conseils!

Answer 1

Contre et contre lesquels ne pas protéger:

N'oubliez pas que les gens trouveront toujours un moyen de contourner votre période d’essai. Vous voulez donc que la personne soit gênée de devoir contourner votre période d’essai, mais peu importe s’il est impossible de contourner votre période d’essai.

La plupart des gens vont penser que c'est trop de travail d'essayer de contourner votre période d'essai s'il existe même un mécanisme simple. Par exemple, les utilisateurs peuvent toujours utiliser filemon / regmon pour voir quels fichiers et entrées de registre changent lors de l'installation de votre logiciel.

Cela étant dit, un mécanisme simple est préférable, car il vous fait perdre moins de temps.

Voici quelques idées:

• Vous pouvez effectuer un décompte quelque part dans le registre pour chaque jour unique qui est exécuté. Si cocher compte > 30 puis montrez-leur un message expiré.
• Vous pouvez enregistrer la date d’installation, mais vérifiez bien s’ils disposent de plus de jours que votre version d’essai n’est censée être, puis dites-leur qu’ils ont expiré. Cela vous évitera que les personnes changent leur date avant de l'installer à une date ultérieure.
• Je vous recommande d'effectuer votre désinstallation, de supprimer vos "jours d'utilisation". compter. En effet, des mois plus tard, les gens pourraient réévaluer votre produit et éventuellement l'acheter. Mais s'ils ne peuvent pas l'évaluer, ils n'achèteront pas. Aucun utilisateur sérieux n’aurait le temps de désinstaller / réinstaller simplement le logiciel pour profiter davantage de votre produit.

Essais en cours:

Pour nous, lorsqu'un client demande une extension d'évaluation, nous lui envoyons un courrier électronique contenant le programme "TrialExtend.exe". et un code d'extension d'essai. Ce programme contacte notre serveur avec le code d’extension d’essai pour le valider. Si le code est validé, leur période d'essai est réinitialisée.

Answer 2

Quoi que vous fassiez, gardez un œil attentif sur la date du système. L'astuce la plus ancienne du livre consiste à installer une application à un moment ultérieur, puis à revenir à la date réelle une fois que l'application a stocké la date idiote lors de la première exécution. Peut-être synchroniser la clé avec un référentiel en ligne?

Answer 3

La réponse de Brian est excellente, mais j'aimerais ajouter quelque chose.

Les utilisateurs de Linux ne sont généralement pas habitués à payer pour un logiciel, et ils ont tendance à être plus férus de technologie et peut-être même "religieux". sur les problèmes open-source.

Pour cette raison, je vous conseillerais vraiment de garder les choses simples - il ne s'agit en fait que d'un petit obstacle qui fait que l'achat du logiciel est aussi simple que le voler.

Je suggérerais que cela décoiffe ou désactive certaines fonctionnalités (par exemple, la sauvegarde) après la période d’essai plutôt que de mourir complètement. Juste une observation, mais les restrictions basées sur les fonctionnalités semblent plus courantes dans le monde Linux.

En passant, faire de la version linux une "première classe" la version - installateur décent etc. aidera.

Si vous êtes relativement petit ou que votre programme est un créneau, il y a peu de chance que quelqu'un prenne la peine de le casser - concentrez-vous donc sur la création d'un bon produit avec un petit geste simple une fois le temps écoulé.

Answer 4

Si vous êtes [assez] susceptible d'avoir une connexion réseau, vous pouvez demander à l'installateur de s'enregistrer sur votre site Web, puis de vérifier son contenu à chaque démarrage.

Si cela n’est pas faisable, écrire une valeur dans un point modifiable du monde sur le système de fichiers (une entrée de registre, une entrée dans un fichier / etc conf, etc.) peut être exploitable.

Answer 5

Le véritable problème est peut-être l’essai limité dans le temps. La société pour laquelle je travaille travaille beaucoup avec Active Directory et nous limitons généralement notre logiciel à un petit nombre d'utilisateurs pour les versions d'évaluation. Je pense que limiter les fonctionnalités d'une certaine manière est parfois préférable, plus facile à mettre en œuvre et n'échoue pas lorsque l'utilisateur change simplement la date sur son ordinateur.
Il existe un problème d'équilibre en ce sens que vous ne pouvez pas limiter la fonctionnalité de manière trop stricte, sinon les utilisateurs ne retireront rien de la période d'essai. Dans le même temps, une limite trop lâche n'incite pas à l'achat.