More than once, I've built a software library - usually something required in specialized industries - which I've then gone on to sell to enterprise customers. Each time, however, I feel that I'm leaving money on the table by pricing it wrong.<p>It does not seem wise to charge a fixed one time fee of a few hundred bucks when the customer then uses the library for years in their own products. Is it still common to charge per installed CPU/core? How do you then deal with cloud systems where that number always changes and may even be difficult to determine? What about charging "per end user"? In general, can libraries also be charged on an ongoing basis like a SaaS (x EUR per month or year), i.e. do customers accept that?<p>I've offered maintenance and support packages but when the software works beyond the initial warranty, customers usually don't order them. I could turn the library into an API and charge for that but that's not always what the customer wants.<p>Any ideas on how to maximize my revenues here?
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.<p>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.<p>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).<p>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.<p>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.
My company buys a math library. It's normally licensed per-core, annually, with a license key that expires and makes it stop working.<p>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.<p>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.<p>The alternatives are:<p>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.<p>2. Paying someone to improve Octave. Probably similar to case 1, but we would feel good about our contribution.<p>3. Very expensive alternatives.
> It does not seem wise to charge a fixed one time fee of a few hundred bucks<p>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.
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.<p>Personally, I'd do a fixed one time fee for each major version of the library.<p>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.
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.<p>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?
You should charge "per month/year", if you have any intention of supporting your product and your customers long term.<p>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.<p>Good luck.