7

I have built a Java library, which I am planning to sell. It will be used as a project's dependency and most users would use it with their build tools such as Maven, Gradle, etc. I wanted to know if somebody is already doing something similar and what selling model they followed. I am thinking:

  • Per-user pricing: Based on the number of users or developers using the library. The catch is here, since it will be used as a dependency, the team can purchase a single license and several users can utilize the API.
  • Project-based pricing: Based on the number of projects the library will be used in. This is probably more straight-forward in this scenario and, assuming the sale is made for 1-5 projects at a fixed cost, it is easier for the end-customer to understand how the installations work.

To me, project-based pricing seems a little more sensible and easier to understand from the user's perspective. However, I wanted to see if there are better models out there that the community uses in such scenarios.

Improve this question
5
  • What is your greater strategy?
    – Jankapunkt
    Commented Mar 17, 2018 at 17:51
  • I have done much rearach and the above 2 models are what I have been able to find. At this point I am only thinking of finding a way to put the product on sale with a selling model that makes the most sense and clear to the user..
    – clayton
    Commented Mar 17, 2018 at 20:37
  • This question is unanswerable - it really depends on your goals, who your clients are, your distribution channel, your product (updates, how frequently ...) etc. etc. ... In the end it will still be opinion-based, even if we have all information.
    – Daniel
    Commented Mar 19, 2018 at 12:22
  • put your library into private space and charge them one time for the project. But then again it really depends on what you want.
    – Raghunandan
    Commented Mar 21, 2018 at 17:39
  • where do you even sell? is there a marketplace (appstore) to sell a Java library? also once they have the jar file they can do anything they want with it. how will you know if they are violating the license?
    – morpheus
    Commented Dec 5 at 2:02

3 Answers 3

Reset to default
3

A project on which I'm involved uses a 3rd-party library among its Maven dependencies.

What the 3rd party did was to set up a Maven repository on the public Internet, protected by a username and password. My company pays a yearly fee to the 3rd party to have access to their Maven repo. We configure their repository in our Maven settings file, and that's it.

Obviously, having an account technically means we can use the latest version of the library in any project we need. I don't have access to the contracts between my company and the 3rd party, though, so maybe some more severe limitations are defined there and maybe legally we can't do that.

Hope it helps.

Improve this answer
3

My answer is purely anecdotal, but I am a software dev who worked for a distributer that sold civil engineering software. (It was an application rather than an API/library.)

The model was a bit of a gray area: they would sell licenses per user but for larger businesses they would make per-business agreements that would mean they could get X licenses for Y fee on a per-project basis. The nature of civil engineering is to work per project, so when a client won a big project for a highway, dam, etc. they would hire more civil engineers and then approach us saying, "We are working on project X and need Y licenses. What kind of deal can you do?" For smaller clients, the sales model was simply per user with no wiggle room.

Improve this answer
2

1) Pay for each user. It wouldn't work. Reason: we have team of 100 developers, but your library is only used by the server when it builds the application. You get the idea.

2) Pay for each project. It is ok... if... if your library is used by a big company with strict policies and they prefer the more legal way to the simpler way. And the simplest = why pay, when we already have it?!

3) Pay for each company. It is convenient for you and for them. One-time payment for license. BUT it won't generate much money in long run...

4) Pay for time. They pay for a subscription on a monthly/annual basis. It is simple, convenient for both sides - AND regularly generates money for you!!! In this case, the company becomes your client for a long time, they always remember you, and you can sell them your new products. This is the BEST way today for handling business.

5) Pay per connection or per action. Something like the API for google.translate. 10k requests for 5$. If your library is used for online requests, you can easily add a counter for this.

As a result: I recommend you to use model #4 - REGULAR PAYMENT FOR USE.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.