Necesita asesoramiento para implementar una prueba de tiempo limitado

Question

Estoy desarrollando una aplicación de escritorio shareware. Estoy en el punto donde necesito implementar el código de prueba de uso / activación. ¿Cómo te acercas a algo como esto? Tengo mis propias ideas, pero quiero ver qué piensa la comunidad stackoverflow.

Estoy desarrollando con C ++ / Qt. La plataforma prevista es Windows / Mac / Linux.

¡Gracias por tu consejo!

Answer 1

De qué protegerse y de qué no protegerse:

Tenga en cuenta que las personas siempre encontrarán una manera de evitar su período de prueba. Por lo tanto, desea que sea molesto para la persona tener que sortear su período de prueba, pero no importa si es imposible evitar su período de prueba.

La mayoría de las personas pensarán que es demasiado trabajo intentar sortear su período de prueba si incluso hay un mecanismo simple. Por ejemplo, las personas siempre pueden usar filemon / regmon para ver qué archivos y entradas de registro cambian al instalar su software.

Dicho esto, un mecanismo simple es el mejor, porque desperdicia menos tiempo.

Estas son algunas ideas:

• Puede hacer un recuento de ticks en algún lugar del registro por cada día único que se ejecute. Si la cuenta cuenta > 30 luego muéstreles un mensaje caducado.
• Puede almacenar la fecha de instalación, pero diríjase a comprobar si tienen más días disponibles de los que se supone que es su versión de prueba, y luego dígales que han caducado. Esto protegerá contra las personas que cambian su fecha antes de la instalación para un día futuro.
• Recomendaría hacer su desinstalación, eliminar sus " días de ejecución " contar. Esto se debe a que las personas pueden reevaluar su producto meses después y eventualmente comprarlo. Pero si no pueden evaluarlo, no comprarán. Ningún usuario serio tendría tiempo para desinstalar / reinstalar solo para obtener un uso adicional de su producto.

Ampliación de pruebas:

Para nosotros, cuando un cliente solicita una extensión de prueba, le enviamos un correo electrónico automatizado que contiene un programa "TrialExtend.exe" y un código de prueba extendido. Este programa contacta a nuestro servidor con el código de extensión de prueba para validarlo. Si se valida el código, se restablece su período de prueba.

Answer 2

Hagas lo que hagas, vigila la fecha del sistema. El truco más antiguo del libro es instalar una aplicación en algún momento en el futuro y luego volver a la fecha real una vez que la aplicación almacenó la fecha tonta en la primera ejecución. ¿Quizás sincronizar la clave con un repositorio en línea?

Answer 3

La respuesta de Brian es excelente, pero me gustaría agregar algo.

Los usuarios de Linux generalmente no están acostumbrados a pagar por el software, y tienden a ser más conocedores de la tecnología y posiblemente incluso "religiosos". sobre cuestiones de código abierto.

Por esa razón, realmente recomiendo que sea simple: en realidad es solo una pequeña barrera para hacer que comprar el software sea al menos tan fácil como robarlo.

Sugeriría que moleste o inhabilite ciertas funciones (por ejemplo, guardar) después del período de prueba en lugar de morir por completo. Solo una observación, pero las restricciones basadas en características parecen ser más comunes en el mundo de Linux.

Como comentario aparte, hacer que la versión de Linux sea una "primera clase" versión - instalador decente, etc. ayudará.

Si eres relativamente pequeño, o el nicho de tu programa es relativamente pequeño, hay una posibilidad bastante pequeña de que alguien se moleste en descifrarlo, así que concéntrate en hacer un buen producto con una simple queja una vez que se acabe el tiempo.

Answer 4

Si es [bastante] probable que tenga una conexión de red, puede hacer que el instalador se registre en su sitio web, luego verifíquelo cada vez que se inicie.

Si eso no es factible, escribir un valor en un punto modificable del mundo en el sistema de archivos (una entrada de registro, entrada y / etc conf file, etc.) puede ser viable.

Answer 5

Quizás el verdadero problema es la prueba por tiempo limitado. La compañía para la que trabajo hace mucho trabajo de Active Directory y generalmente limitamos nuestro software a una pequeña cantidad de usuarios para las versiones de prueba. Siento que limitar la funcionalidad de alguna manera es a veces mejor, más fácil de implementar y no falla cuando el usuario simplemente cambia la fecha en su computadora.
Existe un acto de equilibrio en el que no se puede limitar la funcionalidad demasiado estrictamente, de lo contrario, los usuarios no obtienen nada de la prueba. Al mismo tiempo, un límite demasiado flojo no ofrece incentivos para comprar.