Comment pourrais-je implémenter une fonction "d'autodestruction" dans la version d'essai gratuite de mon logiciel?
Il y a l'argument actuel de l'essai gratuit contre un modèle freemium (c'est-à-dire une version gratuite à vie de leur logiciel avec des fonctionnalités restreintes et/ou supprimées) pour permettre aux clients et utilisateurs potentiels de tester le fonctionnement de leur produit. D'après mes recherches, je peux conclure que l'essai gratuit est la voie à suivre à la fois au profit de l'expérience utilisateur de la personne utilisant le logiciel et au profit du vendeur dans les deux aspects des ventes et de l'utilisation maximale. Il existe de nombreux facteurs pour un logiciel d'essai gratuit qui peuvent maximiser considérablement l'utilisation des utilisateurs, comme la durée de l'essai gratuit.
Un mot-clé qui revient sur mes recherches pour "freemium" est "frustrant". De nombreuses personnes ont choisi de désinstaller le logiciel au lieu d'avoir à utiliser un logiciel où certaines fonctionnalités n'étaient pas disponibles. Dans le même temps, ces utilisateurs n'ont jamais eu la possibilité d'utiliser les fonctionnalités "payantes". À leur insu et cachés par les propres vendeurs qui vendent le logiciel, ils ne savent pas et ne peuvent pas savoir quels avantages les fonctionnalités Pro apporteront. Sans avoir à les utiliser au préalable, un utilisateur ne saura pas qu'il a le sentiment d'avoir "besoin" de quelque chose. Ce qui m'amène à mon prochain point d'un modèle d'essai gratuit.
Certaines opinions d'un utilisateur d'essai gratuit est "Je ne peux pas imaginer utiliser ce logiciel sans les fonctionnalités Pro." Cela remonte au point où "l'utilisateur ne sait pas qu'il a besoin de quelque chose jusqu'à ce qu'il comprenne d'abord le sentiment d'avoir". Ceux qui ont eu 14 jours pour utiliser les fonctionnalités de la version "complète" ont déclaré qu'ils ne pouvaient pas imaginer ne pas avoir ou utiliser les fonctionnalités fournies. Donc, après quatorze jours, ils étaient plus susceptibles de dépenser de l'argent que quelqu'un qui n'a jamais expérimenté toutes les fonctionnalités. La durée de l'essai gratuit est également un facteur important qui crée une impression durable sur les utilisateurs. Dans une expérience menée par Visual Website Optimizer, ils ont remarqué que pour un essai gratuit de 14 jours contre un essai gratuit de 30 jours, alors que le nombre d'inscriptions et d'installations étaient les mêmes, l'utilisation de l'essai de 14 jours a augmenté de 102%. Bien sûr, cela a également augmenté leurs revenus.
Un autre point très important à mentionner est que "proposer une version gratuite et entièrement fonctionnelle du produit" est TRÈS IMPORTANT. Les essais gratuits entièrement fonctionnels sont efficaces pour obtenir une couverture médiatique, et cette publicité pour les nouveaux logiciels et/ou éditeurs de logiciels est assez cruciale.
Un autre aspect pertinent est l'importance pour les utilisateurs de donner leur avis. Considérez, dans l'essai gratuit entièrement fonctionnel et limité dans le temps, la possibilité pour les utilisateurs de donner leur avis.
Une autre caractéristique importante pour notre logiciel est le besoin de données télémétriques, c'est-à-dire des données quantitatives et complètes sur la façon dont un utilisateur utilise notre logiciel. Certaines statistiques d'utilisation peuvent tomber dans une zone grise légale, car les lois sont différentes selon l'emplacement aux États-Unis et dans le monde. Une façon de lutter contre ce problème juridique consiste à disposer d'une fonction d'activation pour collecter des statistiques d'utilisation anonymes. Une fonctionnalité d'opt-in signifierait donner à l'utilisateur une option pour désactiver la collecte de statistiques et en même temps, l'utilisateur doit être très conscient de ce que fait la collecte d'informations d'utilisation anonymes. Il est important d'indiquer clairement à l'utilisateur quelles données seront collectées, ce que "nous" allons en faire, et de le désactiver facilement à tout moment, notamment en lui permettant de changer d'avis pour l'activer ou le désactiver. Pour des statistiques plus détaillées, comme le suivi des activités individuelles des utilisateurs, cela pourrait entraîner des problèmes juridiques. L'Eclipse IDE enregistre des statistiques d'utilisation détaillées, mais il le fait avec le plein consentement de l'utilisateur. Il se peut que nous devions potentiellement préparer un formulaire de consentement avec notre équipe juridique.
La collection d'informations d'utilisation d'Eclipse recueille ces informations: 1. Plug-ins démarrés par le système. 2. Commandes accessibles via les raccourcis clavier et actions invoquées via les menus ou les barres d'outils. 3. Lorsque la "vue" de l'éditeur est mise en évidence. 4. Informations système telles que la version du logiciel utilisé, le système d'exploitation utilisé. 5. Description des erreurs internes.
Antidémarreur
Un kill switch pour notre logiciel peut être géré en enregistrant les données initiales, en les chiffrant avec un sel, et chaque fois que c'est une date invalide, c'est-à-dire que l'utilisateur a essayé de la changer, cela désactiverait le logiciel. Une autre option consiste à disposer d'une authentification Internet à l'installation, à enregistrer cette date dans une base de données Web centrale et à vérifier la date à chaque ouverture de l'application.
En désactivant le logiciel, nous pouvons supprimer les DLL vitales. L'option d'avoir à payer pour générer un rapport ne peut pas être envisagée.
Je souhaite implémenter une version d'essai gratuite de mon logiciel existant. Je prévois que le procès dure 14 jours. Le 14ème jour, mon logiciel inciterait l'utilisateur à payer pour la version payante, ou aurait pour conséquence de ne pas pouvoir l'utiliser. La version d'essai gratuite est entièrement déverrouillée, ce qui signifie que toutes les fonctionnalités payantes sont là.
Cependant, mon dilemme concerne la "meilleure" manière de mettre en œuvre ce qu'il faut faire pour une solution de fin d'essai. Dois-je supprimer des DLL vitales? Vous avez un système d'authentification des utilisateurs lors de l'installation ou de l'utilisation? Crypter la date et l'heure initiales d'utilisation avec un sel, et si c'est une date invalide (AKA ils essaient de changer leur date initiale), désactiver le logiciel?
Je souhaite savoir quelles sont les mesures efficaces de désactivation des logiciels.
Il y a deux problèmes ici - l'un est un problème de programmation et l'autre est un problème commercial. Pour le second, demander aux programmeurs une analyse commerciale est à peu près le meilleur conseil que vous pouvez obtenir de votre chauffeur de bus local; c'est-à-dire que cela peut être bon ou terrible, mais vous ne demandez pas à des experts, donc n'accordez aucun poids inhérent à tout cela. (En passant, un de mes chauffeurs de bus me donne souvent de bonnes idées.)
Mais en ce qui concerne un problème de programmation, l'inconvénient est qu'il semble que la plupart des gens n'aiment pas l'idée au départ. Il y a beaucoup de bonnes raisons à cela, mais elles ne sont pas vraiment importantes ici. Malheureusement, nous sommes également, à certains égards, un groupe terrible de personnes à demander, car en raison de notre position et de nos connaissances, la plupart d'entre nous sont sacrément bons à pirater des logiciels au point que nous pensons qu'il est inutile d'essayer de mettre en œuvre des mesures d'essai. !
Le fait est que votre problème principal est un problème d’analyse d’entreprise et d’expérience de vente, et il n’y a pas de réponse si ce n’est d’apprendre à connaître vos clients et d’expérimenter. Il ne semble pas que vous ayez déjà un grand groupe de clients avec qui parler de leur pipeline de vente de produits et de la façon dont vous pouvez implémenter un logiciel d'essai pour l'améliorer, il faut donc comprendre que nous sommes maintenant en mesure de poignarder aveuglément dans le noir . La première étape pour travailler dans une pièce sombre est sachez que vous en êtes un!
Alors, commencez quelque part. L'objectif n'est pas la bonne réponse, car je ne peux garantir à 100% qu'une chose - vous n'allez pas commencer par la bonne réponse. Mais nous devons commencer.
Donnez à vos clients un baiser
Aussi, "restez simple, stupide." Ou, à partir d'une méthodologie de programmation, "essayez la chose la plus simple qui pourrait fonctionner." Ensuite, partez de là.
Donc, lors de l'installation, obtenez une date. Le ranger. Obtenez vos données sur les installations et l'utilisation, et profitez de la chaleur que l'analyse des données peut apporter. Désactivez la partie du logiciel que vous souhaitez à la fin de la période d'essai - je suggère if (trial_expired()). Ajustez ensuite.
Tout d'abord, obtenez de bonnes données. Envisagez-vous de fournir des mises à jour à l'avenir pour votre logiciel? Alors, si quelqu'un essaie de battre v1.0, ne vous inquiétez pas.
La chose la plus simple est de désinstaller le logiciel, puis de le réinstaller. Nouvelle période d'essai (car votre logiciel a supprimé cette ancienne date). Ça t'intéresse? Si la v1.0 est sur le point d'être mise à jour, alors je vous suggère fortement de trouver un moyen de savoir si cela se produit - mais n'essayez pas de les arrêter (encore). C'est comme les gens qui prennent 2 menthes au lieu de 1 - c'est juste une menthe, laissez tomber. De toute façon, ils n'allaient probablement pas vous payer pour ça.
Comment? Eh bien, sous Windows, cela se faisait généralement en enfonçant des clés orphelines aléatoires dans le registre et des fichiers étrangement nommés dans divers répertoires d'installation courants. Votre installateur prétendrait explicitement qu'ils n'existent pas et les laisse simplement là. Le niveau de sophistication informatique que cela nécessite pour vaincre est bien plus que la désinstallation.
Mais si vous n'essayez pas d'empêcher quelqu'un de réinstaller, vous obtenez les données dont vous aurez besoin. Ici, ils ne volent pas votre magasin - ils vous donnent une occasion précieuse d'étudier un client potentiel. Utilisez-le pour personnaliser votre marketing, les invites d'aide du logiciel, les campagnes par e-mail, les "offres spéciales". J'essayais de détecter l'événement et puis, un jour plus tard, je leur envoyais une clé qu'ils pouvaient entrer dans le programme pour prolonger leur essai jusqu'au mois prochain. Vous pourriez trouver une méthode qui les transforme en clients payants ou non; aucun moyen de savoir à l'avance!
Cela semble anodin, mais avouons-le - avez-vous vraiment besoin de plus que cela? Si vous collectez des données, cela vaut de l'argent pour vous. Vous voudrez probablement passer du temps à vous assurer que les e-mails sont bons, à concevoir une messagerie logicielle que vous pouvez mettre à jour pour guider les nouveaux utilisateurs (arguments de vente invisibles, vraiment), à réécrire le texte de présentation de votre application, à éliminer les bugs qui empêcheraient toute personne sensée d'acheter votre logiciel en premier lieu, etc.
Mais la clé ici est que vous communiquez honnêtement et clairement à tous les clients potentiels - si vous le souhaitez, vous devez nous payer. Ce n'est pas parce que vous êtes (invisiblement) magnanime que c'est un logiciel gratuit - vous allez juste être intelligent et ne pas chasser les clients parce qu'ils n'ont pas conclu l'accord au cours des deux premières semaines.
Si vous y réfléchissez, ces gens viennent dans votre magasin pour vraiment regarder votre produit. Ils font un essai routier, mais cela ne vous coûte (presque) rien. Aucun magasin prospère n'a réussi à chasser les clients qui n'étaient pas encore prêts à acheter! Pourtant, nous savons tous si vous pouvez obtenir quelque chose gratuitement, pour toujours, pourquoi payer? Utilisez donc le meilleur des deux mondes.
À chaque étape, vous travaillerez sur un filtre et si votre logiciel est bon, vous effectuerez des conversions à chaque étape. Ma simple suggestion:
1) Essai gratuit de 14 jours
2) Prolongez l'essai gratuit, sans poser de questions
3) Proposez de prolonger la période d'essai gratuite, s'ils sont si gentils de remplir un court formulaire qui vous communique leurs opinions sur votre logiciel jusqu'à présent.
4) Êtes-vous sûr que ces personnes qui utilisent encore votre logiciel n'envisageront pas de l'acheter? Trouvez un moyen de les séduire - ou essayez au moins de leur fournir plus d'informations sur ce que vous pourriez faire pour que d'autres achètent. Peut-être leur permettre de `` demander '' une extension via un formulaire, que votre personnel de vente accordera avec bonté, puis utilisera les informations pour voir s'il peut faire face à toute objection qu'il pourrait avoir à acheter votre logiciel.
Que faire si cet utilisateur l'évalue pour une utilisation dans l'ensemble de son service? Si la réunion budgétaire a lieu le mois prochain, voulez-vous vraiment qu'ils ne puissent pas utiliser le logiciel jusque-là?
5) Peut-être que vous les coupez maintenant ... et peut-être que vous les invitez pour une offre spéciale une semaine plus tard avec un rabais. Peut être pas. Peut-être que vous proposez d'étendre pour donner une extension finale.
Ces personnes ne vous doivent pas d'argent, alors traitez-les comme de futurs clients potentiels - pas comme des voleurs, des freeloaders ou des personnes qui ont besoin de payer leur facture ou de désactiver leur service. Tout le monde déteste les collectionneurs de billets, alors n'agissez pas comme tel.
Par programme, avouons-le - ce n'est pas vraiment difficile. Utilisez des fichiers orphelins pour garder une trace des dates. Si vous devez avoir un compte valide comme via iTunes, ce suivi est beaucoup plus facile. Si ce n'est pas nécessaire, je vous suggère généralement de ne pas l'exiger pour une première installation - ne détournez jamais les gens de la première version car ils ne veulent pas remplir un formulaire stupide. Les gens détestent les formes! Et ils ne connaissent pas votre logiciel, alors pourquoi "payer" pour remplir un formulaire s'ils ne savent même pas si votre application fonctionne?
À l'étape 2, je recevrais une inscription/e-mail à étendre. Encore une fois, la programmation est triviale.
3) Après 30 jours, j'aurais probablement besoin d'une sorte de comportement de "téléphone à la maison". Si les gens vont casser ça - comme ils le font - félicitations-friggin-lations! Vous devez devenir assez populaire. Mais ne vous inquiétez pas, si ce n'est pas un jeu vidéo, les gens ne s'en soucient probablement pas assez, alors changez simplement votre code dans la prochaine version et faites-les revenir à la planche à dessin.
TL; DR;
# 1 Ne résolvez pas un problème que vous n'avez pas vraiment (vous n'êtes pas encore Adobe - DRM peut être simple et efficace si vous n'y pensez pas trop). # 2 Ne demandez pas à un programmeur quand vous avez besoin de demander à un agent de commercialisation, un analyste commercial ou un vendeur. # 3 Traitez vos clients comme des gens qui pourraient vous donner leur vie, pas comme des gens qui vous doivent de l'argent, et surtout pas comme des voleurs. # 4 DRM est vraiment, vraiment, facile. Ne pensez pas que vous allez empêcher les gens d'utiliser votre logiciel qui ne vous donneront certainement jamais, jamais, jamais d'argent ... du moins pas aujourd'hui.
- J'ai acheté des logiciels que j'ai piratés, des années plus tard. Alors ne faites pas chier les futurs clients inutilement non plus.
Vous cherchez quelque chose qui est essentiellement impossible. Certaines des entreprises les plus importantes et les mieux financées de l'industrie du logiciel ont passé des années, et des millions et des millions de dollars, à chercher un moyen d'accomplir ce que vous essayez de faire, et cela n'a jamais réellement produit de bons résultats.
Tout d'abord, vous pouvez tout oublier de visser une installation locale. Tant que le programme d'installation d'origine existe toujours (ou peut être sauvegardé ou téléchargé à nouveau), ce n'est rien de plus qu'un ralentisseur. Même placer quelque chose quelque part dans les paramètres système signifie très peu lorsque l'utilisateur peut installer sur une image VM puis sauvegarder et restaurer l'intégralité de l'image VM.
La prochaine étape évidente est l'authentification en ligne: configurez un serveur et demandez au programme de "rappeler à la maison" chaque fois qu'il démarre pour vérifier les informations d'identification. Cela ne fonctionne pas non plus. Tout d'abord, vous rencontrez un problème évident (et très frustrant) de faux négatifs lorsque le serveur est en panne ou inaccessible pour une raison quelconque, ou a un problème dans son logiciel. Et vous ne pouvez pas faire que le logiciel valide simplement l'utilisateur automatiquement s'il ne peut pas atteindre le serveur, ou il est trivial de contourner l'authentification avec quelques astuces de mise en réseau, ou simplement en l'utilisant sur une machine avec le wi-fi activé de. (Et bien sûr, cela signifie que les gens qui essaient de l'utiliser légitimement avec une bonne raison de ne pas avoir de connexion Wi-Fi, comme apporter leur ordinateur portable avec eux dans le bus, seront verrouillés. Cela ne fera personne comme votre programme.)
L'autre problème avec l'authentification en ligne est qu'en fin de compte, cela se résume à un booléen quelque part dans votre code. Quelque part, il appelle AuthenticateUser() et s'il renvoie True, l'utilisateur est entré et s'il renvoie False, il est verrouillé. Et peu importe ce que vous faites pour crypter, obscurcir ou masquer le code, au final, cela se résume au simple fait que si un ordinateur peut le lire à un moment donné, un programmeur le peut aussi. Quelqu'un, quelque part, va produire un crack où AuthenticateUser retourne toujours True, et ils le mettront sur le Web.
Le problème fondamental de la cryptographie peut être décrit comme "Alice veut envoyer une lettre à Bob, sans que Charlie puisse la lire même si elle devait tomber entre ses mains." Le problème avec ce que vous voulez, c'est que Bob et Charlie sont la même personne, ce qui rend votre objectif impossible.
Si vous voulez gagner de l'argent avec votre logiciel, tordre les bras de vos utilisateurs n'est pas la solution. Ce qui fonctionnera, la chose seulement qui fonctionne de manière cohérente de nos jours, est la théorie de base du marché: offrez un produit que l'utilisateur perçoit comme ayant une plus grande valeur pour lui que le prix que vous lui demandez, et il sera prêt à payer. Tout le reste ne sera qu'une perte de temps et d'efforts de votre part.
Juste mon 2 ¢.
Une auto-destruction fiable à 100% est impossible. Il y aura toujours un moyen sophistiqué de casser votre protection.
Ce que vous pouvez faire est de rendre l'utilisation ou le crack d'un essai expiré plus compliqué que l'achat d'une version complète pour votre marché cible.
Si j'étais à votre place, j'essaierais de faire en sorte que mon logiciel soit: (1) populaire, donc tout le monde intéressé au moins l'a essayé, et (2) à un prix raisonnable, afin que ceux qui sont prêts à payer puissent l'acheter, et vous tournez un bénéfice. Le reste des utilisateurs peuvent jouer avec les essais expirés au contenu de leur cœur: ils ne l'achèteraient pas de toute façon, mais ils contribuent à la popularité et fournissent plus de recrutements potentiels aux entreprises qui achètent réellement votre logiciel.
Je suppose que le marché cible d'un plug-in Revit est composé d'architectes, d'entrepreneurs en construction, de concepteurs, de toutes les personnes gérant des sommes d'argent relativement importantes par contrat, et sans excès de temps libre ou d'expertise informatique de bas niveau.
Assurez-vous donc que votre version d'essai expirée ennuie suffisamment eux sans réellement casser quoi que ce soit (ou ils vous détesteront). Les gens qui ont besoin de travail finiront par céder et paieront le prix [raisonnable].
Quelques idées:
- Faire une version d'essai rapidement (et proprement) se désinstaller à l'expiration. La réinstallation devrait être possible, afin que les utilisateurs voient leur travail intact, suivi d'une autre désinstallation automatique peu de temps après.
- Laissez la sortie d'une version expirée inclure une marque ou un texte disant "Fabriqué avec une version ESSAI EXPIRÉ de [votre logiciel]". Un utilisateur sérieux ne montrerait pas une telle sortie à un client. (Et s'il le fait, encore une fois, il est trop bon marché pour payer votre logiciel de toute façon).
- Faites en sorte qu'une version d'essai expirée affiche des boîtes de message à des moments aléatoires, avertissant que l'essai a expiré et donnant un lien vers la version complète. De telles choses interrompent suffisamment le flux de travail pour qu'une mise à niveau en vaille la peine pour un utilisateur sérieux.
Toute combinaison d'astuces habituelles peut être appliquée pour marquer un ordinateur comme ayant un essai expiré: clés de registre cryptées, fichiers cryptiques à des emplacements aléatoires (n'oubliez pas de restaurer l'horodatage si vous les modifiez), masquer les horodatages dans des fichiers graphiques non liés ou autres formes de stéganographie, etc.
Bien sûr, si l'utilisateur, par exemple réinstalle le système d'exploitation, il bénéficiera à nouveau d'une période d'essai gratuite. Qu'à cela ne tienne: un client sérieux n'y recourra guère. Bien sûr, ce schéma éventuellement sera craqué; assurez-vous que votre logiciel est suffisamment populaire d'ici là pour que vous puissiez proposer une mise à niveau avec des fonctionnalités intéressantes et un schéma de protection différent.
Comme exemple de "logiciel de dérangement" très réussi, je choisirais des maquettes Balsamiq. Vous pouvez utiliser leur logiciel gratuitement (sur le Web), avec certaines fonctionnalités limitées, y compris la sauvegarde de votre travail. Le travail peut être "exporté" et "importé" avec quelques tracas. Autrement dit, tout élève du secondaire qui veut jouer avec la version gratuite presque entièrement fonctionnelle peut le faire, et peut même avoir du travail. L'étudiant ne l'achètera pas de toute façon. Mais un designer sérieux qui apprécie son temps et sa commodité l'achètera.
Comme autre exemple très réussi, je prendrais bien sûr MS Windows.
Ce n'est pas difficile à faire. Cela dépend vraiment de l'effort que vous souhaitez y consacrer.
N'oubliez pas, le but d'une version d'essai est d'augmenter les ventes. Tous les schémas de versions d'essai pour les logiciels installables peuvent théoriquement être contournés par certains moyens, même si cela implique des efforts considérables, car le code est exécuté localement et peut donc être édité avec un éditeur hexadécimal. Cette réponse part de l'hypothèse que l'affiche originale pose des questions sur des solutions pratiques à ce problème commercial, pas sur des questions théoriques.
Comme l'une des autres affiches mentionnées, il s'agit de s'assurer que l'effort nécessaire pour contourner le système de version d'essai dépasse le coût en termes de temps et d'effort que le coût d'achat du logiciel. Les `` pirates '' dédiés téléchargeront simplement les versions pré-craquées de votre logiciel en utilisant BitTorrent . Ne vous inquiétez pas pour eux, car ils ne seraient pas des clients de toute façon. Les approches ci-dessous ont été adoptées par d'innombrables éditeurs de logiciels depuis des décennies, et tant que vous n'êtes pas paralysé par l'idée que ces systèmes doivent être théoriquement parfaits, vous constaterez qu'ils fonctionnent assez bien dans le monde réel.
Au niveau le plus simple, vous pouvez simplement conserver une "fenêtre" de date de début/date de fin dans le registre (cryptée). Chaque fois que le programme s'exécute, vous vérifiez que l'heure système se situe entre ces deux dates et mettez à jour le composant 'start' de cette date. Cela empêche l'utilisateur occasionnel de simplement remettre l'horloge à zéro pour permettre l'accès à la version d'essai.
Vous pouvez l'étendre en gardant une trace de cette fenêtre temporelle à plusieurs endroits (à la fois dans le registre et dans le dossier de données de votre application) et en vous assurant qu'ils correspondent à chaque démarrage. Cela empêche les gens de manipuler les entrées - ils doivent savoir exactement où ils se trouvent et comment décrypter/crypter les données.
Il existe également un certain nombre d'autres façons de resserrer les choses, que vous rencontrerez sûrement lorsque vous commencerez à développer la fonctionnalité d'essai.
Si vous ne voulez pas faire tout cela vous-même, il existe de nombreuses bibliothèques tierces qui offrent ce type de fonctionnalité.
Remarque concernant la suppression effective de fichiers: Si votre application essaie de supprimer des fichiers, elle peut être signalée comme malware par le logiciel anti-virus de l'utilisateur. Le logiciel antivirus est très très agressif de nos jours. Et de nombreux utilisateurs finaux seront convaincus qu'il existe un virus dans votre logiciel si leur programme antivirus affiche une alerte.
Cela dépend de la difficulté avec laquelle vous voulez que vos clients potentiels contournent ces fonctionnalités auto-désactivantes (cela sonne mieux que "l'autodestruction"). En supposant que vos clients potentiels n'essaieront pas de manipuler le code du programme lui-même (que certains d'entre eux essaieront, croyez-moi), vous avez les options suivantes:
stocker la date et l'heure initiales quelque part (cachées) sur l'ordinateur sur lequel votre logiciel est installé: cela a l'inconvénient que vos clients peuvent facilement le contourner, par exemple, en installant votre programme sur une machine virtuelle et en le désinstallant après la période d'essai par réinitialiser le VM à son état d'origine
assurez-vous que chaque copie téléchargée de votre programme a un temps de téléchargement codé en dur individuel quelque part caché dans le code binaire du programme. Cela nécessitera beaucoup plus d'efforts administratifs de votre part, et vous ne pouvez toujours pas être sûr que la même personne ne télécharge pas une nouvelle copie du programme depuis votre serveur après la période d'essai (peut-être en utilisant une identité différente)
livrer la version d'essai uniquement avec un "dongle" où la fin de la période d'essai est stockée. Cela ne sera possible que pour les programmes avec une poignée de clients potentiels et un prix bien supérieur au prix du dongle.
faire de la chose une application Web, ou des parties de celle-ci, ou simplement une application connectée au Web. Dans ce cas, vous pouvez stocker la date initiale sur votre serveur, mais vous devrez identifier et distinguer les personnes qui utilisent votre logiciel (par exemple, en définissant des cookies ou en créant une connexion). Mais encore une fois, vous ne pouvez pas être sûr à 100% que les gens ne changent pas d'identité.
Quoi que vous fassiez, assurez-vous de tester très attentivement ce qui se passe au-delà de la date d'expiration. Une fois, j'ai travaillé pour une entreprise qui distribuait des logiciels avec un système d'essai semblable à celui que vous décrivez. La différence était que l'expiration était une date fixe dans le futur.
Nous avons abandonné le programme immédiatement après avoir reçu une tonne d'appels de clients en colère lorsque leurs versions légitimement achetées ont également cessé de fonctionner à cette date.