2008-10-13 8 views
21

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

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

Gracias por su consejo!

+0

No relacionado, pero tenga en cuenta que si desarrolla aplicaciones comerciales con QT * debe * tener una licencia de desarrollador de QT. La licencia de QT prohíbe usar la edición de código abierto para software comercial, que incluye shareware. Consulte http://trolltech.com/products/appdev/licensing/licensing para obtener más detalles. –

+3

Gracias por el consejo. Tenemos una licencia comercial. No quisiera molestar a los trolls ... – JimDaniel

+0

Eso es bueno de escuchar :) Trolltech ha dado tanto a la comunidad que siento la necesidad de defenderlos, incluso si no es necesario ... Me alegra ver que estás apoyando ellos. –

Respuesta

23

Lo que hay que proteger en contra y lo que no debe proteger contra:

Tenga en cuenta que la gente siempre encontrará una manera de conseguir alrededor de 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 el período de prueba.

La mayoría de las personas pensarán que es demasiado trabajo para tratar de evitar su período de prueba si hay incluso 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.

Habiendo dicho eso, un mecanismo simple es mejor, porque desperdicia menos tiempo.

Aquí están algunas ideas:

  • Usted puede hacer un recuento de la garrapata en algún lugar de registro para cada día único que se ejecute. Si marca el conteo> 30, muéstreles un mensaje caducado.
  • Puede almacenar la fecha de instalación, pero verifique si tienen más días disponibles de lo que se supone que es la versión de prueba, y luego dígales que han caducado. Esto protegerá a las personas que cambien su fecha antes de instalarlo en un día futuro.
  • Yo recomendaría hacer su desinstalación, eliminar su cuenta de "días en funcionamiento". Esto se debe a que las personas pueden volver a evaluar su producto meses después y finalmente comprar. 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.

ensayos Ampliación:

Para nosotros, cuando un cliente solicita una extensión de prueba, los enviamos un correo electrónico automático que contiene un programa de "TrialExtend.exe" y un ensayo extender código. Este programa se pone en contacto con nuestro servidor con el código de extensión de prueba para validarlo. Si el código es validado, su período de prueba se restablece.

+1

'Ningún usuario serio tendría tiempo para desinstalar/reinstalar solo para obtener un uso adicional de su producto. - Ciertamente lo haré –

3

Hagas lo que hagas, mantente atento a 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. Tal vez sincronizar la clave con un repositorio en línea?

+0

Para evitar eso, uno puede usar el valor absoluto de System.currentTimeMillis() - expirationDate.getTimeMillis(); Lo siento, soy un chico de Java. Atentamente, Steff – Snicolas

0

Si tiene [bastante] probabilidad de tener una conexión de red, puede hacer que el instalador se registre en su sitio web y luego verifique que no se repite cada vez que se inicia.

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

+2

Tenga cuidado con esto. Los usuarios son muy cautelosos con los programas que "llaman a casa": no tienen forma de saber qué devuelve, podrían ser sus números de tarjeta de crédito y sus contraseñas bancarias por todo lo que saben. –

2

La respuesta de Brian es genial, 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" en cuestiones de código abierto.

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

Sugeriría que molesta o desactiva 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 un aparte, hacer que la versión de Linux sea una versión de "primera clase" - un instalador decente, etc. ayudará.

Si usted es relativamente pequeño, o su programa es relativamente nicho, hay una pequeña posibilidad de que alguien se moleste en descifrarlo, así que concéntrese en hacer un buen producto con un simple inconveniente una vez que se acabe el tiempo.

0

Tal vez el problema real es la prueba de tiempo limitado. La empresa para la que trabajo hace un montón de trabajo en Active Directory y, por lo general, limitamos nuestro software a una pequeña cantidad de usuarios para versiones de prueba. Considero que limitar la funcionalidad de alguna manera a veces es mejor, más fácil de implementar y no falla cuando el usuario simplemente cambia la fecha en su computadora.
Hay 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 incentiva la compra.

Cuestiones relacionadas