cocoa framework

Implementando una contrarreloj de 30 días (9)

Considera esto. ¿Cuántos usuarios potenciales de su software están disponibles, simplemente ansiosos de usarlo de manera sólida durante los próximos 30 días?

Sospecho que el caso más común es el siguiente: los usuarios encuentran un nuevo paquete de software que resuelve un problema que han tenido en un sitio como lifehacker.com. el software se descarga, se reproduce brevemente y luego se deja de lado. Tal vez su software de extracción de mp3 y no tienen ningún CD para rasgar en ese momento. O simplemente están ocupados ese día, pero se darán la vuelta para revisar ese software ''pronto''.

30 días pasan. Probablemente más. Solo entonces compran un CD, encuentran algún tipo de "problema" y recuerdan: "¡Ajá, hay una versión de prueba que descargué! ¿Dónde lo puse de nuevo? No importa. Sin haber sido usado nunca, la ''prueba'' ha expirado.

No puedo contar la cantidad de herramientas de software que han caído en ese cubo para mí. El día en que se me recomienda una pieza de software, el día que veo una revisión positiva en lifehacker, NUNCA es el día en que realmente tengo una necesidad, o incluso el tiempo, de usar / analizar el programa que descargué e instalé.

Pregunta para los desarrolladores independientes de Mac por ahí:

¿Cómo implemento una prueba contrarreloj de 30 días de una manera no maligna? Poner un contador en las preferencias no es una opción, ya que borrar las preferencias una vez al mes no es un problema para un usuario promedio. Poner el contador en un archivo oculto en alguna parte suena un poco dudoso, como un usuario que odio cuando las aplicaciones salpican mi disco duro con archivos aleatorios. ¿Algunas ideas?

En el momento de la descarga, proporciónales un número de serie de prueba. Cuando ingresan el número de serie, haga que se conecte a su servidor y obtenga la información de vencimiento (almacenada y encriptada localmente para evitar llamadas adicionales de "teléfono a casa").

Al hacerlo de esta manera, les dificulta bastante eludir su ventana de 30 días, ya que la fecha de caducidad está permanentemente almacenada en el servidor. Podría configurarlo, por lo que eliminar la clave y volver a ingresarla ocasionaría que su aplicación se conectara nuevamente a su servidor y descargara la misma fecha de caducidad que antes.

O puede hacerlo como lo hace WinZip (¿o solía hacerlo?): Proporcione una versión de prueba de 30 días y solo muestre una pantalla emergente en cada carga que muestre por cuánto tiempo la ha estado usando y enlaces para comprar.

Este problema aparece repetidamente en la lista de correo de cacao-dev y la respuesta de consenso siempre es hacer lo más simple posible. Los piratas informáticos decididos romperán todas las soluciones excepto las más ingeniosas. Y es poco probable que paguen el software de todos modos. Vaya por la solución 80/20: la solución fácil que obtiene un 80% de efecto con un 20% de esfuerzo. En este caso, poner algo en ~ / Library / Application Support / your.app.com /. Podría nombrar el archivo algo inocente si quiere ofuscar las cosas un poco. Usar los valores predeterminados del usuario también es fácil.

Hagas lo que hagas, no uses la dirección MAC u otra identificación de hardware. Los usuarios con un directorio de inicio de red (por ejemplo, en una configuración de laboratorio compartida) te odiarán. Usar identificadores de hardware es simplemente malo.

Si alguien está tan enamorado de tu programa que está dispuesto a romper tus límites de prueba, déjalos. El software libre no le cuesta nada y su buena voluntad (y tal vez recomendación a los demás) vale mucho.

Finalmente, escriba el software que las personas quieran usar y cámbielo por su valor. Si su precio es bueno y la gente quiere usarlo, la mayoría de las personas lo pagará.

Lea un UUID de algún componente de hardware y compruebe su servicio web para ver si su software ya se ha instalado durante 30 días después del lanzamiento del programa.

Lo hicimos para una de nuestras aplicaciones cliente. De acuerdo, se hizo en .NET para Windows, pero los mismos principios se pueden aplicar en MAC.

Como mencionó Eckesickle, si su usuario tiene acceso a Internet (o debería), entonces puede tener un servicio web que registrará una identificación única de la computadora host con la fecha de inicio de prueba (la dirección MAC es buena). Con esto, el usuario no puede engañar realmente al programa a menos que tenga su tarjeta de red cada mes.

Ahora, si el usuario no tiene acceso a Internet por alguna razón, puede cerrar el programa hasta que se conecte o use un período de gracia. Este archivo registra la última vez que se abrió la aplicación. Cuando no se puede acceder a Internet, dejamos de escribir la hora (aún escribimos algo en ella para que el usuario no note que el archivo no está actualizado).

Si un usuario nota que este archivo contiene la información y la elimina (o la cambia usando una copia que tiene), entonces necesita una forma de contrarrestarla. Puede tener algún otro valor en otro archivo de configuración (cifrado siempre) y verificar la coherencia. Lo que haces si descubres que el usuario está tratando de hacer trampa depende de ti, pero forzamos al usuario a conectarse a Internet para que funcione.

Puede ser excesivo para un programa, pero definitivamente funciona.

Solía ofrecer una edición lite de 30 días de mi aplicación para iOS que incluía la fecha de instalación y varias fechas de registro en el archivo de datos de exportación que el usuario podía descargar a su computadora.

Si el usuario era tacaño y acaba de volver a instalar la edición lite e intentó volver a importar los datos, la lógica se daría cuenta de que al menos una de las fechas era anterior a 30 días y la aplicación establecería su fecha de instalación a la fecha más temprana de el archivo, lo que hace que caduque nuevamente.

En la edición paga completa, esta lógica no existía y el archivo de datos se podía importar fácilmente.

Fue un dolor apoyar a las personas en esta migración de datos (ya que las aplicaciones están completamente aisladas entre sí) y algunos otros usuarios sintieron que la edición lite era suficiente para ellos, por lo que nunca se actualizaron.

Desde entonces he dejado de ofrecer mi edición lite y solo he reducido el precio de la edición completa. Ahora los clientes potenciales solo tienen que pagar una pequeña cantidad o buscar algún software que compita.

En general, esa fue la mejor estrategia para conseguir usuarios de pago.

Sugeriría implementar algunas cosas que son menos intrusivas y pueden evitar que un usuario normal desinstale o compre en un período de un mes.

Use una serie especial de número de serie de prueba que almacene la fecha de caducidad. Puede usar encriptación para almacenar la fecha de caducidad dentro del número de serie.
Ahora crea un archivo de configuración que almacena datos en el formato encriptado y contiene el número de serie.

Además, implemente estas cosas en el archivo de configuración.

Anote la hora / fecha cada vez que el usuario inicie la aplicación.
Tenga en cuenta que la duración de la aplicación de tiempo fue abierta.

Al hacer el registro de la marca de tiempo, puede evitar estas soluciones:

Si el usuario revierte la fecha de la computadora, sabrá que la aplicación ya se ejecutó ese día. Digamos que el usuario ejecutó la aplicación el 1 y 3 días del mes. Ahora, después de 30 días, invierte la fecha y la establece en el 2 de mes. Ahora, mediante el archivo de configuración, sabría que la aplicación ya se ejecutó en 1 y 3, por lo que el usuario ha dañado las fechas en la computadora.
Digamos cada vez que el usuario inicia su aplicación configurando primero la fecha hasta el 5 del mes. Al registrar el tiempo de ejecución de su aplicación, verá que si el total de horas en un día supera 24, entonces el usuario está bromeando.

Asegúrese de que su aplicación no se ejecute sin el archivo de configuración. Entonces, esencialmente, usted envía el número de serie encriptado en un archivo o tal vez al ingresar el número de serie, puede crear un archivo. Como el número de serie ya tiene la fecha de caducidad, el usuario tampoco puede volver a utilizar el número de serie.

No recomendaría la forma de Internet porque la gente se cabrea cuando la aplicación intenta conectarse al servidor todo el tiempo. Además, uno puede sospechar que intenta enviar datos personales de usuarios a sus servidores.

Una cosa que quisiera decir es que no importa qué tan fuerte sea la técnica antipiratería que use, alguien está obligado a romperla. No estás haciendo tu aplicación para esos tipos. Está haciendo su aplicación para las personas que deseen su software y lo comprarán felizmente. Entonces, tenga la antipiratería dentro de los límites sin perder a los clientes genuinos al hacer que su aplicación sea demasiado intrusiva durante el período de prueba. Un pensamiento también dice que si tu software se está agrietando eso significa que también se está volviendo popular. De nuevo, las opiniones pueden diferir y no me gustaría hacer una digresión sobre estos temas.

Tener el software caduca después de 30 días calendario es malo porque ¿qué pasa si alguien lo descarga, lo ejecuta una vez y luego decide que lo evaluará un mes después? La próxima vez que lancen, un mes después, dirá que ha caducado.

Me gustaría tenerlo limitado a 14 lanzamientos, o algo así como 120 minutos de uso.

En cuanto a la implementación, un archivo (oculto o no) en la carpeta de Preferencias del usuario, con un nombre ofuscado, parece ser el mejor camino a seguir. El archivo no se coloca aleatoriamente en el disco duro, pero el usuario no puede determinar fácilmente qué archivo eliminar.

La forma menos dañina es simplemente pedirle al usuario que elimine el programa después de un mes o que lo pague;)