Venta de bibliotecas Java: ¿qué modelo de precios elegir?

Question

He construido una biblioteca Java, que estoy planeando vender. Se utilizará como dependencia de un proyecto y la mayoría de los usuarios la usarían con sus herramientas de construcción como Maven, Gradle, etc. Quería saber si alguien ya está haciendo algo similar y qué modelo de venta ha seguido. Estoy pensando:

• Precio por usuario: Basado en el número de usuarios o desarrolladores que utilicen la librería. La trampa está aquí, ya que se utilizará como una dependencia, el equipo puede comprar una sola licencia y varios usuarios pueden utilizar la API.
• Precios basados en proyectos: Basado en el número de proyectos en los que se utilizará la biblioteca. Esto es probablemente más sencillo en este escenario y, asumiendo que la venta se hace para 1-5 proyectos a un coste fijo, es más fácil para el cliente final entender cómo funcionan las instalaciones.

Para mí, la fijación de precios basada en proyectos parece más sensata y más fácil de entender desde la perspectiva del usuario. Sin embargo, quería ver si hay modelos mejores por ahí que la comunidad utilice en estos escenarios.

Answer 1

Un proyecto en el que estoy involucrado utiliza una biblioteca de terceros entre sus dependencias de Maven.

Lo que hizo el tercero fue crear un repositorio de Maven en la Internet pública, protegido por un nombre de usuario y una contraseña. Mi empresa paga una cuota anual a la tercera parte para tener acceso a su repositorio Maven. Configuramos su repositorio en nuestro archivo de configuración de Maven, y eso es todo.

Obviamente, tener una cuenta técnicamente significa que podemos utilizar la última versión de la biblioteca en cualquier proyecto que necesitemos. Sin embargo, no tengo acceso a los contratos entre mi empresa y la tercera parte, por lo que tal vez algunas limitaciones más severas se definen allí y tal vez legalmente no podemos hacer eso.

Espero que sea de ayuda.

Answer 2

Mi respuesta es puramente anecdótica, pero soy un desarrollador de software que trabajó para un distribuidor que vendía software de ingeniería civil. (Era una aplicación más que una API/biblioteca).

El modelo era un poco gris: vendían licencias por usuario, pero para las empresas más grandes hacían acuerdos por empresa que significaban que podían obtener X licencias por una tarifa Y por proyecto. La naturaleza de la ingeniería civil es trabajar por proyecto, así que cuando un cliente ganaba un gran proyecto para una autopista, una presa, etc. contrataba a más ingenieros civiles y se dirigía a nosotros diciendo: "Estamos trabajando en el proyecto X y necesitamos Y licencias. ¿Qué tipo de acuerdo pueden hacer?". Para los clientes más pequeños, el modelo de venta era simplemente por usuario, sin margen de maniobra.

Answer 3

1) Pagar por cada usuario. No funcionaría. Razón: tenemos un equipo de 100 desarrolladores, pero su biblioteca sólo es utilizada por el servidor cuando construye la aplicación. Ya te haces una idea.

2) Pagar por cada proyecto. Está bien... si... si tu biblioteca es utilizada por una gran empresa con políticas estrictas y prefieren la forma más legal a la más sencilla. Y la más sencilla = ¡¿Por qué pagar, si ya lo tenemos?!

3) Pagar por cada empresa. Es conveniente para ti y para ellos. Un solo pago por la licencia. PERO no generará mucho dinero a largo plazo...

4) Pagar por el tiempo. Pagan una suscripción mensual/anual. Es simple, conveniente para ambas partes - ¡¡Y regularmente genera dinero para usted!! En este caso, la empresa se convierte en tu cliente durante mucho tiempo, siempre se acuerdan de ti, y puedes venderles tus nuevos productos. Esta es la MEJOR manera hoy en día de manejar los negocios.

5) Pago por conexión o por acción. Algo así como la API de google.translate. 10k peticiones por 5$. Si su biblioteca se utiliza para las solicitudes en línea, usted puede agregar fácilmente un contador para esto.

Como resultado: Le recomiendo que utilice el modelo #4 - PAGO REGULAR POR USO.