I've developed and sold several libraries over the years. Here's how I approached pricing. I'm not saying this is the best way, but it has worked for me.

I don't really do ongoing payment (rental) schemes, out of pure personal preference. (If a customer asks for one, I can do that, though -- it's just not a default option). I don't like it when other software does this, so I'm not going to do it myself. That's not an economic or business-based decision and not a recommendation. I'm just mentioning it to explain why that's absent here.

I take a look at what my development costs were to develop the library, and use that to estimate what it would cost another shop to replicate the same functionality. I try to subtract out the portion of the development costs that are reflect the API design and other things that are unique to library development (including documentation).

Then, once I have an estimate for what it would cost my potential customers to develop the functionality, I cut that in half, and that becomes my asking price.

I also sell libraries in two forms: with source code and without. For those who want the source code (which is most of my customers), I charge double what the asking price I computed above is.

Trying to figure out how much it would cost the customer to develop the same functionality is probably the best strategy (and suggested by most posters in this thread).

I would add that the customer may not come up with a detailed estimate/calculation so it's more a question of how expensive they perceive their development costs to be. (If their developer casually says, "I can do this in two days", that's bad even if it's wrong.)

One probably has to factor in the (possible) inefficiency of the customer, i.e. inexperienced devs and the usual overhead of working at a large company.

At first, I thought that by cutting the costs in half, you would end up with a fairly low price. But giving them the option to receive the source code at double the price is a nice touch, especially since you say most of your customers want that anyway.

My company buys a math library. It's normally licensed per-core, annually, with a license key that expires and makes it stop working.

We eventually worked out a special deal where we would pay for 2 years at a time in advance, and get a version without the stupid expiring key.

The library vendor trusts us to account for the number of CPUs we are running it on and self-report. We don't abuse that trust.

The alternatives are:

1. Writing our own math library. We estimated it would take a man-month to get it usable, but we might spend years in corner cases.

2. Paying someone to improve Octave. Probably similar to case 1, but we would feel good about our contribution.

3. Very expensive alternatives.

> It does not seem wise to charge a fixed one time fee of a few hundred bucks

Maybe you could make the one-time price higher? I've seen some critical libraries cost several thousand dollars, and it was worth it in time saved.

I would have to agree with this. In the days when .NET was top dog and GitHub was not still a thing people spent insane amounts of money for libs that would save them time. Per client, per developer, per "seat", per core, anything you can think of someone charged for it. Telerik is the one that comes to mind, but they mostly did dev-oriented stuff.

The pay-more-once scheme always seemed the most easy choice for companies I worked for, as they wanted to be able to sell products that they couldn't easily keep charging for after the sale.

This is my approach with my own libraries (and it's what I look for in libraries I buy from others). I would rather pay four or five figures one time than to have to put up with making regular payments over time. In part for convenience, but mostly to avoid nonsense like registration keys and the like, and I prefer not to ask my customers to deal with things that I'm not willing to deal with myself.

That said, as a small businessperson I have considerable flexibility. If a customer really wants a lease option, I can easily accommodate that.

Your customers are going to ask if it's cheaper to buy your library or build out the functionality on their own. If I were pricing this, I'd try to be at the highest number possible where the answer to that question is a no-brainer.

Personally, I'd do a fixed one time fee for each major version of the library.

Another option is to scale your pricing based on your customers' revenue like Unity does (minus the subscription part). Smaller companies can get a better deal on your software, but when they cross a threshold of annual revenue, then they pay more.

> Another option is to scale your pricing based on your customers' revenue

I don't scale the pricing in an overt way, but I have been known to reduce the fee for small companies or individual developers if they ask.

Also, if I think a particular customer would give me additional benefits (such as increased exposure or clout), I have sometimes cut the rate in exchange for permission to advertise their use of my library.

Look into charging per developer, with a site license option. Libraries / components, especially for enterprise development is big business. In the .Net space you have $100m+ companies like DevExpress and Telerik, and smaller, more specific and niche component providers (example: componentspace.com) selling successfully at a few grand a copy.

A few hundred bucks is way too low for any library of substance that saves the local developers a few weeks work.

Value-based pricing is an alternative to cost-based pricing. Try to quantify the value that your library brings to the customer in terms of revenues generated or costs saved. You and the customer should get to share this value, so choose a price that divides that value between you equitably.

I think for a library an annual 'support license' on top of the purchase fee, would keep your pockets padded - since it's niche say you charge $400 for the library, then $80/year -- if you have enough clients that's some residual on-going income just be sure to push out a few security updates per year which is what the subscription aspect is for -no subscription --what's your motivation to provide support/upgrades?

This is the worst advice in this thread by far. $80 would barely cover one hour of work.

If you charge any support, this should be similar or more than the price of the library. Clients who ask for support are the most annoying ones who are planning to use it and the bigger companies with deep pockets.

Better make the support crystal clear on what is covered because clients might try to have you do the integration in their software, which is a whole development project, not a support task.

Support mostly (to me) means maybe a forum/knowledgebase + on-going updates/patches/fixes. In person/hands-on help would of course be an hourly feature at $100+ per hour. But many use cases won't need that kind of support, for most the docs and updates/upgrades are worth the subscription.

If it's a niche shouldn't you charge way more? $400 sounds really low to me.

You should charge "per month/year", if you have any intention of supporting your product and your customers long term.

Sell the library for X EUR, and then charge Y Eur/year for ongoing support and maintenance, where Y is a fraction of X. If the user does not want the support and maintenance, so be it, they can use the software indefinitely. In my experience, most serious users have no problem paying for long term support.

Good luck.