Usage-based software license models that are effective will tend to balance two criteria – flexibility to meet the needs of the software consumers who are using the software to accomplish a task, and predictability of costs in order to satisfy the Finance departments of both the software vendors and consumers. Usage-based software license models can be difficult to perfect because of the seeming complexity, but by balancing predictability with flexibility, a practical model can be developed.
The "Remix" software license model was developed in the Electronic Design Automation (EDA) market in the late 1990’s. EDA software is provided from suppliers such as Synopsys, Cadence, Mentor Graphics, Magma, Atrenta and others is used by manufacturers of electronic components and systems, such as Apple, Intel, AMD, nVidia and others to design their electronic products. The EDA software market has several characteristics that led to the creation of new software license models:
- High Value and High Software Licenses: The software performs complex design and analysis functions in a wide range of computing environments (desktop, server, or compute farm) that are crucial to developing electronic products in a short time frame. It’s very expensive to simply overbuy and over-equip engineers.
- A wide portfolio of products: There is a design flow that starts with "design capture" and proceeds through functional simulation and physical design. After all, it’s important to know if a particular chip will really work at lower power in the complexity of an iPhone before you manufacture millions of them. But there is a challenge; it is difficult to know when a project start the exact profile of software that is required due to nuances and problems in the electronic design process.
- The Need to Use Operational Expense Budget (OPEX): Many electronic companies prefer to expense the software costs to particular projects, in order to manage the ROI on a project basis.
The resulting Remix License model evolved after iterations and experiments in the larger enterprise customers. The essence of the model is to allow customers to replace low utilization software (shelf-ware) with software that is expected to be used with higher frequency. There are some variations to the model, but the framework is characterized below:
- At the core is multi-year license usage agreement, usually 2-3 years for a fixed yearly fee. This provides an element of financial predictability.
- Each software title is assigned yearly usage price values, that when added up, yield the total yearly price of the agreement.
- At the beginning of the agreement, the customer will declare a mix of software titles (and associated quantities) to meet the bulk of their usage requirements. Adding up the yearly price of the software mix, will yield the total yearly price of the deal.
- Periodically (quarterly, semi-annually, or annually), the customer can change a fixed percentage of their mix of software licenses to reflect changing usage patterns Typically, 25% of the total yearly value of the agreement can be changed. For example, if there is a $1M annual fee, then any collection of software in the contract whose yearly license fees multiplied by quantity are equal to $250K can be swapped out for a similar total value of software licenses.
A few things to note about the model from a revenue recognition perspective (which requires good counsel from your Finance department to understand):
- As with most time-based license models, the software vendor must recognize revenue ratably over the course of the agreement.
- You need to be careful to avoid providing access to products not available at the time the agreement was constructed, or more severe revenue deferral processes may be involved.
The tactical deployment of the model requires the users of the software to be able to measure and report on software usage in order to identify software utilization profiles. To date, that hasn’t been an issue in the EDA community, where such tools have already been widely deployed.
In other technical markets with similar challenges, the "token license model" is another license model variant that has been successful.
Next time – how do you approach software pricing such a license model, especially if your perspective is a classic perpetual license model?