By: John Lipsey
Intelligent device manufacturers are facing a world of change.
Think Monetization Before Enforcement with Subscription Software Licensing Models
By: Cris Wendt
If you are a software vendor, a subscription software license model can be an excellent addition to your product pricing portfolio. The subscription software licensing model can offer a lower cost of entry for your customer, making it a more cash-flow friendly if they need to closely manage cash flow. The subscription license model is often accounted as an operational expense rather than a capital budget item for the buyer, which may also be appealing to your customers who prefer this method of purchasing software (this is popular with engineering software where software license procurement is viewed as a project expense). And for the vendor, the subscription software license model offers the promise of a more predictable annuity revenue stream. This is quite appealing to a CFO who can plan and budget more accurately with known revenue streams. Of course, the subscription software license model isn't always a fit for all software in all markets.
However, there are cases where we find that a subscription software license model is a perfect fit for the business, yet the software vendor is reluctant to adopt it. The argument I often hear can be paraphrased as, “Yes, it's the perfect model, but we can't have our software stop running because a license key expired. Our customer's business can't go down.” This is a case of backward thinking – there is an inaccurate technology view of the subscription software license model that affects its adoption.
If the subscription software license model is the right monetization and customer-friendly model then it can and should be adopted. Next is the enforcement decision, which can be applied somewhat separately from the software monetization decision. It too, is a business decision, and not a technology decision.
If your software is mission critical to your customer's business, and if you trust your customer, then your compliance philosophy should be never to stop the customer from running, but to monetize this over-usage when possible. An enforcement mechanism, such as a license manager, does not actually stop software from running. The license manager simply informs the software that the license has expired, and it is up to the business policy coded into the application that decides on what to do. There is an entire range of possibilities from simply messaging a customer that the software license has expired, all the way to the hard stop of an application. In fact, the business policy coded into the product can be designed to vary by a number of factors (mission criticality of product, product lifecycle, geographic region of sale, size of customer, etc.). If your customer is running your software in a mission critical environment, then simply give them a message that their license has expired. And, be sure that the associated entitlement management systems are providing the business information that a license is about to expire so that a sales conversation can be arranged.
Subscription software license models are a great way to grow market share and increase customer satisfaction. If it makes sense, adopt the software license model, and tune the enforcement mechanism to align with your compliance philosophy.
View post:
Think Monetization Before Enforcement with Subscription Software Licensing Models
Anyone for 1 quadrillion intelligent, connected devices on the Internet?
By: Randy Littleson
I came across an interesting article in the last week (Cisco: 50 billion things on the Internet by 2020) that highlighted a debate between Cisco and IBM in terms of how many intelligent, connected devices were going to be connected to the Internet in the next few years.
Improved Customer Experience with Software Licensing & Entitlement Management
By: John Lipsey
EMC is a global leader in enabling businesses and service providers to transform their operations and deliver Information Technology as a service. Constantly on the lookout to improve their customer's experience, EMC examined their software licensing activation process and wanted to enhance the customer experience by finding a solution to help reduce errors, eliminate user authentication complexities as well as eliminate any dependencies on knowledge and information about software licensing during the license activation process.
More Musings on Making Software Licensing and Entitlement Management Solutions a Reality
True Pay-As-You-Go Software Licensing Model – Myth or Reality?
By: Mathieu Baissac
I recently came across this post – Is IT Ready for True Pay-as-you-go Software Model? – on the IT Business Edge blog. In the post, Ann All states, “While customers are eager to take advantage of the pay-as-you-go usage model promised in the early days of the cloud, software vendors are understandably reluctant to give up their large licensing fees and ongoing support and maintenance revenues.”
I wanted to share my perspectives…
- Software vendors for complex software solutions will have a hard time making it simple enough to make it predictable. Look at the Azure/Amazon pricing—it's a mess. I have had several CIOs complain to me already that what they expected vs. what they paid were quite different. When you price 100s of different features—you're going to have a very hard time doing pay as you go models.
- Enterprises will accept some variability – but no more than 5-10% (I suspect). They are accountable to budgets and can't blow them up. In theory, pay-as-you-go is about reducing costs. So the software licensing models must be simple, tied to something fairly predictable and software vendors must provide information to enterprises as they use it. This is why we have meters in cabs.
- Enterprises will want ability to verify the data – especially when the meter is usage-based instead of # of employees or other controllable metrics. Cabs in most countries have placards explaining the metric and the price for each.
- Enterprises won't want to pay weekly/monthly – they will want quarterly or semi-annual payments at most. The cost of invoicing, etc. is large.
Until software vendors can provide simple metrics that are highly predictable/controllable with a lot of verifiable data points, enterprises will not adopt pay-as-you-go software licensing models – even if it means potentially significant savings.
What's your perspective on pay-as-you-go software licensing models?
Read this article:
True Pay-As-You-Go Software Licensing Model – Myth or Reality?
Characteristics of a Successful Software Licensing Program
By: Michael Smith
Licensing is one of those programs where when it's not working well it quickly becomes a top initiative for any CEO.
What the Heck is a Token Software License Model?
By: Cris Wendt
A flexible software license model that is gaining some traction in the market is a token software license model. This model is very effective for software vendors who have a wide portfolio of software where the usage patterns of individual software are difficult to predict. This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment. Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as the usage of software may be dependent upon the challenges faces in a particular design. For example, in electronic design, a particular design may require more simulation software than previous designs have required.
From the perspective of the software vendor, it's also an effective way to fortress a market position against point-tool competitors. The token software license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy the best-of-breed for every part of a design flow.
Expiring Concurrent Tokens
The simplest form of token software license model is implemented (and easiest described) as a variant of a floating license model. With the typical floating license model, each time a particular software product or title is run it checks-out a license key from a license server for the duration of operation. For example “Software A” will request a particular license key associated with “Software A” from a license server whenever it runs. If the license server has licenses available, the software is granted a license to run. The software will return the license to the server when the software is exited. Similarly, “Software B” will request a particular license key associated with “Software B” from the license server whenever it runs.
When deployed as a token license, the software vendor creates a generic license key “token” instead of a license key associated with each product – the idea being that products don't check out product specific licenses, but rather, checkout one or more generic tokens – the amount of which is weighed toward the list price of the product.
SoftwareCEO.com Shares Tips for Software Pricing and Licensing
Bruce Hadley, Founder and Editor of SoftwareCEO.com recently published an article regarding a conversation he had with Steve Schmidt, Vice President for Flexera Software, providers of application usage management solutions for ISVs and intelligent Device Manufacturers. In the article, Steve shared nine (9) software pricing and licensing tips, as well as his thoughts on the hottest trends like cloud computing, SaaS, and subscription licensing. Steve's tips included:
Tip #1: If you have only one pricing and licensing model, you don't have enough.
Tip #2: Add a pricing and licensing model that's subscription-based.
Tip #3: Add a pricing and licensing model that's usage-based.
Tip #4: Your pricing needs to flex, but prepare for the hit.
Tip #5: Add automated mechanisms to support the new model and provide visibility.
Tip #6: Increase scalability within your pricing and licensing model.
Tip #7: Implement flexibility in packaging.
Tip #8: Make your software portable within the pricing and licensing model.
Tip #9: Homegrown solutions aren't likely to survive the long haul.
Bruce comments, “Sure, Schmidt and Flexera have something to sell — but we happen to agree that most ISVs should not attempt to create their own systems for application management. Even if you are capable of building such a thing, it will detract from what should be your primary focus: Improving your own software.”
For the complete, in-depth interview, read the entire article: Flexera Software VP Offers Tips for Software Pricing and Licensing.
Link:
SoftwareCEO.com Shares Tips for Software Pricing and Licensing
The Nuances of Token Software Licensing
By: Cris Wendt
The Token Software License Model (as a variant to the floating software license model) is a great way to provide flexibility to your customers. By selling tokens that can be used to invoke multiple products, you provide a great deal of flexibility to users who can't always accurately predict what to purchase.
Implementation & Planning Considerations
The implementation of tokens as a mechanism to control access to products requires some careful thought and planning. Typically, the Token Software License Model is implemented in conjunction with a license manager technology, such as Flexera Software's FlexNet Publisher software licensing module and operates something like this: before a product operates, it requests to check-out or consume tokens (non-product specific license keys) from the license manager. Based upon the availability of tokens in the pool at the moment of the action (determined by how many tokens were originally sold to the pool less how many tokens were consumed at that moment), the request is either granted or denied. While the implementation of this token license model is easily accomplished in the software when a license manager is present, there are some important policies that need to be established before an implementation begins:
-
How do I determine how many tokens each product requires when it operates? That is, how is a token calibrated to list price? What is the sufficient granularity of value for a token? Is it $500 of list price per token? $1,000 per token?
-
How do I handle list price changes to software? For example, if a product is designed to consume 5 tokens when it runs, what happens when the price of the product changes, especially if the software is already installed in the field? Suppose the new list price warrants that 6 tokens are consumed for each invocation, how do I handle customers that have an installed base of software that checks-out 5 tokens, with software that requires 6 tokens?
- How do I measure the usage of actual products when tokens are consumed? License managers typically record all license key request activity in a usage log for subsequent software asset management and usage profile analysis. In a non-token software license model, a product will consume a license key that is specific to a particular product. That way when the usage log is inspected, the usage attributed to a particular product can be understood by looking at the time that specifically-named license keys are consumed. When generic tokens are check-out instead, all usage is attributed to a generic token and it is impossible to understand which particular product consumed the token.
All of these issues can be easily addressed in a design phase, but they must be carefully considered during the planning and implementation phases.
The Temptation of the Token
One of the more seductive aspects of a token is the capability to allow customers to access future products that were not available at the time the original sale was made. For example, at the time of the sale, it's easy to tell customers that a new, more desirable product will be available in 6 months, and that it will automatically operate with the token system.
While such an assertion is appealing, there is a potentially serious downside—some or all of the revenue associated with the agreement may be deferred until the new technology is available. The topic of revenue recognition was discussed in earlier Subscription Licensing blogs.
It is therefore very important to define and bound the parameters of future technology access whenever customers are provided with such a flexible software licensing model and to carefully consider the impact of revenue recognition.
Read the original:
The Nuances of Token Software Licensing
Common Software License Types and Terms
By: Jill Powell
I was recently asked by a customer to provide some standard definitions of common software licensing terms and thought it might be helpful to others. So here it is…
Appliance: