Before we start, let me state it clearly: we hate licensing just as you do. It’s a necessary evil – but still an evil. In PostSharp 6.6 we’re introducing Per-Usage Subscriptions, a pricing model where you are not charged per daily unique active user but per amount of source code in which you use PostSharp.
With Per-Usage Subscriptions, we’re hoping to lower the barrier to entry for large teams that want to get started with PostSharp without paying a full license fee for all developers.
The price of Per-Usage Subscriptions starts at $250 for PostSharp Ultimate or $10 for PostSharp Logging.
Software development tools have traditionally been priced per user. If your team of 20 uses Visual Studio, you need to purchase 20 licenses. Per-user pricing is simple to explain and enforce. No wonder it has become the de-facto standard in the software development tools industry. It makes sense for an IDE because most developers open it every day. The ROI of Visual Studio would be much smaller for developers who open the IDE once per week, but this would not be a typical situation.
However, not all software development tools have the same economics as an IDE. How do you price, say, a data grid control? Suppose you have 10 devs working on a project and you need one data grid. One developer adds the data grid to the app and spends one week integrating it in the codebase. After the initial developer merges the changes, the whole team will need to be able to build the code. With a per-user pricing model, all 10 developers need to be licensed – for a single instance of the control. This cost is clearly prohibitive.
The caveats of per-user licensing explain many things in our industry: why UI component vendors try to sell large bundles instead of single controls, but also why customers turn to lower-quality open-source products.
(Note for those interested in economics theory. The per-user pricing model does not lead to Pareto-efficient markets because the product price for the customer is not proportional to its utility. Both the buyer and the seller would have interest in doing more business together – the reason of the market inefficiency is not the product, but the pricing model itself.)
So, how to make the cost of PostSharp more proportional to its usefulness? One of the most important metrics of utility of PostSharp is how much boilerplate code you avoid writing thanks to it. This metric cannot be estimated with enough precision to serve as a pricing basis, so it is not a good candidate. However, the amount of boilerplate code you save is proportional to the amount of hand-written code to which you apply aspects, and this metric can be reliably and precisely measured.
That’s why we chose to base our new pricing model on the number of lines of code that you enhance with PostSharp.
All developers would agree that counting lines of code is not the panacea. It is a metric, one that’s reasonably simple to measure and one that is proportional to the benefit you get from using PostSharp. It’s a compromise, and we hope that for many customers it’s a better one than counting unique daily active users.
Because this new type of subscription is bound to a specific code base, we require the license key to be checked in your source code repository (in a file named postsharp.config). Anybody cloning and building that code would automatically use this subscription.
There is no industry standard about counting source lines of code (SLOC). Different tools would report very different results. What’s important is to only compare numbers given by the same algorithm.
We chose a counting method that does not depend on code formatting and the amount of blank lines and comments. This method is very fast and precise enough. We count:
We do not count lines of code for: namespaces, generic parameters, or custom attributes.
The granularity level is the class or the struct. If you apply an aspect to a single method of a type, we will count all lines of this type. This, again, is a technical compromise of simplicity and performance, and we understand it may be considered as “unfair” in some situations.
Since the license key of the subscription is stored in your source code repository, and since different developers may work on different subsets of the code base, how do we ensure that developers together do not exceed the number of SLOC?
Short answer: we count on each device, upload anonymized metrics to the cloud, then aggregate per subscription. Daily.
For each C# project, on each device, we compute the number of enhanced lines of code once per day. We create a file, for each project, mapping a non-reversible hash of the type name to the number of lines of code in this type. Then, each day and on each device, we aggregate yesterday’s files for all projects, and upload the aggregate to the cloud. The data ends up in Data Lake Analytics.
If you are not online every day, it does not matter – but we do require an internet connection once per week for this licensing model.
Then, once per day, we run a Data Lake Analytics job to aggregate data per subscription. We prepare detailed reports to be displayed in the customer portal, which looks like this:
Additionally, the script exports summaries for our sales teams. When we notice that the consumption is higher than the entitlements, we will try to contact you and ask you to purchase more.
We trust you by default. We will not break your build before we contact you. If you fail to increase the size of your subscription, we reserve the right to remotely deactivate your subscription.
Consultancies and bespoke development shops will appreciate this: once your project ends, you can transfer the licenses to your customer together with your source code. Seems logical since the license key is in the source repository, doesn’t it? A legal note: there’s an additional form that the three parties need to sign to make the transfer legally effective.
Say you have a team of 100 developers and a code base of 1,000,000 lines of code (1,000 KSLOC): a large system with server, desktop and mobile apps.
You’ve just discovered our [NotifyPropertyChanged] aspect and think you could reduce boilerplate on your MVVM classes. The per-user price for 100 devs would get you to a 5-digit price: a no-starter for your development director. You estimate that you will need to add 10 KLOC of MVVM code in the next months, so all you need to get started is a PostSharp Ultimate Per-Usage license for 10 KSLOC. Since 1 KSLOC is given for free, your entry price is 9 x $250 = $2,250. This is just 22$ per developer! Now your development director wishes all publishers would propose our licensing model.
After your first experience with PostSharp, you learn about other aspects such as caching or authentication, and you start adding them to your server-side code. As your usage of PostSharp increases, you increase the size of your subscription. Eventually, you may decide that switching to a per-user subscription is best for you. But from the beginning, you’ve enjoyed a maximal return on investment.
Per-user licensing of software has severe caveats and at PostSharp we’ve decided to innovate once again and introduce Per-Usage Subscriptions, a pricing model bound to the amount of code to which you apply PostSharp.
Per-Usage Subscriptions work by counting lines of code for each enhanced type on each developer workstation, uploading the data to the cloud once per day, and aggregating, and making them available on the customer portal.
Thanks to Per-Usage Subscriptions, you can have a huge ROI from the first day. No need for a large upfront investment.
Happy PostSharping!
-gael
UPDATED 2020-07-23 - Renamed Per-Repo Subscription to Per-Usage Subscription
--- ## Site navigation - Index of the whole site: [llms.txt](../llms.txt)