MENU
Software pricing and licensing experts agree that optimal pricing strategies are rooted in value pricing. This means that the customer and the vendor find a satisfying middle ground where the value that the user receives from the software is proportional to the price that he pays.
For standard packaged products this is easy to achieve using a license manager. All you do is to issue node-locked licenses for each user or floating licenses for each concurrent or networked user. Since you get paid based on the number of licenses that you sell, your financial gain scales with the license count.
Sublicensed SDKs pose pricing challenges
Things get more complicated when selling software development toolkits (SDKs). SDKs are usually libraries accessed via API calls. SDKs can sometimes be licensed as you would a packaged product, with a license per user of the finished application. But SDKs are not usually licensed to other ISVs that way because they are incorporated into products that are resold or sublicensed, and it gets too cumbersome to license through to the end user. This article deals with ways to price sublicensed SDKs that are sold to ISVs.
Some Pricing/Licensing Options
Let’s examine some common practices to see which one comes the closest to the ideal model.
1. Charge the same price to all customers. The perils of this strategy are obvious. You cannot be fairly compensated in all cases when you charge the same “average” price to everyone, since your product will be unaffordable to small ISVs and ridiculously inexpensive to large companies, making them wonder whether you can even stay in business at these prices. Clearly, there must be a better way.
2. Charge based on the number of development seats. This seems to solve the scaling problem, except for the fact that some large development groups may be able to handle their requirements by licensing a single development seat. Again, we should be able to do better than this.
3. Charge based on the overall development team size. We’re making progress with this approach, because now you can charge a lower price to license a smaller team, but larger teams may resent the “tax” that you are placing on them – when only a small number of developers ever “touch” your SDK. Is this the best we can do?
4. Charge based on the number sublicensed products. Hmm? This might work. Bigger companies would pay more presumably because they would have more products. But, not always. This pricing would punish smaller companies who, for whatever reason, have larger product portfolios. Still looking for a better idea.
5. Charge based on the number license keys issued. With this method you would get paid based on the number of license keys that are shipped for products that use your SDK. Interesting. This model scales with units sold. Big companies will sell more units, smaller companies fewer, right? Well, not exactly. Companies with high-volume but low-cost products would pay a higher relative fee than companies with low-volume but high-cost products. Aside from the additional resistance that you may get from your ISV customers who would be forced to reveal their detailed product sales data, this strategy still misses the one great equalizer – revenue.
The Optimal Pricing Strategy
We’ve found that the best pricing strategies for sublicensing SDKs are based on revenue. The rationale is that all sublicensed products incorporating software from your SDK benefit equally, proportional to the value (price) of the sublicensed product. By building pricing models that scale with revenue, you can assign fair prices that correspond to the annual revenue of your ISV customers, regardless of number of developers, sites, products or keys issued. You can even assign your customers a revenue band or range so that they do not have to reveal their revenue in detail.
Once you settle on suitable revenue-based price levels, you can experiment with various models of payment, such as annual subscriptions or tiered (paid-up) licenses. Ultimately, you need to be flexible, but starting price negotiations with a fair and sensible model is the best first step.