Software Licensing Part 3: Pros & Cons
In My previous post in this series I discussed how the license models technically function. Here we go with a bit of pros/cons on Technical & Cost management, Vendor Monetization & relevance to Cloud Standards. Named License: Technical managment is straight forward as the license is bound to a user name. This can get tedious if you have a lot of username changeover (very typical in the AEC space) since you would have to release and reassign the license slot on a constant basis. Cost management based on the one to one ratio makese accounting & charge back easy. The downside is unless the vendor has given you 4:1 or better ratio of users:license count vs. other many:1 ratio licensing methods described below, you are probably paying to much/user. Vendor nonetization is great as they are protected against the dilution of their price model since it is one to one. Buyers however want vendors to stay in business, so it's often just considered the way it is for the industry to profit and some what of a baseline for the other license models. Talking cloud standards, this model is limited in scalability due to the 1:1 user:license lockin. Unless you are using a SaaS model (bundling software and service which presents a host of other considerations) or the payment method changes to subscription (like the Microsoft SPLA, Citrix CSP, and My company offers) it is difficult to enable month to month scaling of the license count.
Concurrent License: Techncial management is simple because the license just sits there and gets taken/released as a user hits it. Cost management is generally the same or better than named as you will get an N:1 ratio of users:license count. Generally speaking you will see a concurrent license priced 2:1 or 3:1 vs. a named license. The truth is you get more like 4:1 and I've seen as high as 10:1 on a consistent monthly basis. Since the User count fluctates per license, you just need an accounting method to track system users vs. application users for back charging. I'll discuss such software in another post. Monetization is usually mesmerizing, as they tend to show it as 2:1 or 4:1 vs. a comparable 1:1 named license of equal features. I suppose this is just of those confusing things like paying 2X or 3X for training vs. consulting when the consultant is usually far more experienced than the trainer. Talking cloud, the model is more scalable than named licensing because the number of system users is not relevant to the number of licensed application users. You can add all you want but are still limited by the quantity currently logged in to the application. Like named licensing, this would be remedied by widespread availability of Subscription licensing.
Site License: Technical management is best because their is no restriction imposed by the application vendor on the number of users that can be logged in to the application at any given time. Infrastructure and application load capability is the only limitation. Cost management is very similar to concurrent licensing and simply becomes and excercise in n:site or users:cost and how you charge it back to projects or business units. Vendor monetization is simlar to concurrent licensing. Always a hint of chicken vs. egg; either named licensing is out there to make this confusing, or this should be the standard which would then make named licensing monetization a mystery. In my career widespread use of named licensing came along more recently, so a good site license price is generally a good choice. Site licensing also tends to be offered for a larger user base, another good reason vendors do this since they have generally recovered and exceeded any planned revenue once the user count exceeds a certain qunatity. From a cloud perspective, very scalable so it hits the nail on the head here. The addition of a SPLA/CSP model would result in better cashflow management assuming parity in cost with other license models.
Processor License: Technical management, like site licensing, is systems management issue vs. a vendor license issue. The main issue here is waiting on Moore's law to give you better server/processor/core performance so you can get more out of your application license investment. Cost management is like concurrent & site licensing, again as long as you can wait on Moore. If you buy new servers that introduce more processors, then you may have some considerations but any back charging is still functionally the same as other N:1 license models. Vendor monetization is also along the lines of concurrent and site license models, a bit of dice in the air for similar reasons. Talking cloud, very similar to concurrent and site license models.
Project License: Everything is nearly identical to site licensing except it is limited to a project. This license model essentailly makes the project the technical equivalent of a single tentant otherwise known as a customer, business unit or cost center. Since this type of business management is very prevalent in the AEC Industry it can be a good way to enable project independance or incremental adoption of a new product. If a company is using project licensing and the application across many or all the projects in their portfolio, it is likley they are paying more/user than they would using one of the other license models.
Revenue Based License: This model is not very prevalent, I suppose because it requires some level of business insight by the vendor into the customer's revenue in order to charge for the license. To me this is clumsy and intrusive. Although the Vendor gains/loses in line with the customer revenue, I'm not sure I understand how the customers revenue has anything to do with the value of software from a vendor perspective unless it is somehow directly tied to the customers success. Perhaps I'll be enlightened inthe future. Like most products it seems the vendor should have a price based on what it costs to make the product, a fair profit, and maintain a healthy business. Where I currently see this concept the most viable is for internal company back charging. It makes a lot of sense for a company to charge back IT services as a whole based on the revenue of a project for example. As noted above, more on back charging in a future post.
So there we have a few Pros/Cons. In the next post, I'll wrap this series up with a few summary points and where we might be headed.