What if an equipment manufacturer provides true value (premium) through the free software delivered with, or used in conjunction with the (automated) equipment, and is not charging for it? Where does this practice of hidden software cost and value come from? How does it align with the increasing role and value equipment related software has? What pricing models could overcome this?
This paper is about the trend of value pricing in the equipment manufacturing industry, where prices are traditionally based on cost-plus, and where software is part of the machine, not separately priced, let alone be priced based on value.
The fact that software used to be free, and the notion that software should be free, founds its origin on two grounds:
- Traditionally, it was hidden within equipment with no visibility to the user
- In the consumer industry, there is a lot of free software
This sounds too good to be true, and it is. There are large hidden costs, especially when the demand for keeping the software up-to-date is increasing. The support costs were traditionally absorbed in the equipment engineering costs, are financed by new sales of software.
In this paper, we discuss the necessity of value-pricing all software on-board and surrounding industrial equipment.
First, we briefly discuss the increasing value of the software in equipment delivery and operation. Then, we review the practice of hidden and free software and its origins. Finally, we address the various possibilities for pricing models.
When we review the transition of value addition in the 19th and 20th centuries, we observe a transition from manpower to machine power. Step by step, tasks are overtaken by machines, first driven by man, yet increasingly automated. These two steps illustrate two value transitions: firstly, machines made mankind more productive, secondly, machines were made more productive by adding software and other technology.
In the last two decades or so, the increased productivity has come from machine automation, increased machine autonomy (e.g. by adding all kinds of sensors), and increased machine control. All three ways of productivity enhancement are largely driven by software. If the software fails, the machine would produce less, or even worse, wouldn't produce at all. This not only emphasises the value of the software to provide certain functionality, but it also highlights the need for reliability to ensure the stability of production.
Reliability is a challenge more so for software engineers than for equipment engineers. To build in tolerances, an equipment engineer can over design a component, so it is stronger than needed based on the expected working loads. In software engineering, a concept of over design does not exist, and typically works in a counterproductive manner (slow, overly complicated, etc.). In both disciplines, errors are made. However, errors in mechanical designs typically do not result in regular process disturbances (apart from fatigue), whereas errors in software can lead to a frequent disturbance of operations (with the most extreme case: a crash enforcing a restart; even Windows 10 – one of the most used software packages in the world - still has occasional crashes). As a result, software maintenance is as essential as equipment maintenance. Without regular updates, software becomes vulnerable, obsolete, or non-functional. Errors that are identified over time need to be rectified through updates.
The fact that software becomes an increasingly important part of the equipment (even more so in the case of automated equipment) leads to a transition in the design teams behind such equipment. Where traditionally mechanical, hydraulic, and electrical engineers set the tone, nowadays a significant portion is taken care of by software engineers.
In terms of the share in the cost of equipment, this is not yet reflected. Equipment is very much priced on a cost-plus basis: the sum of all components + delivery and commissioning + a certain margin generates the price tag. The value of the equipment was never priced. How many units did it handle or produce during its lifetime? This is not accounted for as it was not the domain of the equipment manufacturer.
Would a freemium model be applicable for the software delivered with the equipment? A basic free version, and a premium set of additional features? In our view the core of the equipment of the future already provides the most important value, and therefore should be paid for. In addition, extra functionality should be payable. One could argue that the basic version of the equipment has no automation, and no advanced controls. In that case, the software that is still there could be for free.
In equipment manufacturing, the (largely) embedded software was hidden, an intrinsic part of the machine. It had no visibility to the user, could not be approached remotely, nor did it evolve. It simply was there from the moment the machine was purchased until the end of life. Hence, when you go around in the industry, you will find ancient software ‘still going strong’ as many will say.
Where the software is basic, with little functionality, it remains possible to continue following this hidden cost model (with "free software" as a result). However, we argue that the software provides essential and ever-increasing value, hence putting a price on that is reasonable and necessary to ensure quality is warranted. Not only do we argue a price upfront should be paid, but the cost to maintain the software during the lifetime of the equipment should also be paid.The latter is becoming even more essential when the software landscape surrounding the equipment, and the software controlling the equipment, also changes. This is, amongst others reasons, caused by the increased connectivity of equipment to the outer world. Ten years ago, few types of equipment had the capability of communicating over networks, but nowadays connectivity is almost a given. As much as this provides opportunities – e.g. for getting real-time data out of the equipment which can be used for various purposes, or remote control over the equipment - it also provides threats, when someone with malicious intentions gains access. Therefore, interfaces need to be maintained, and security against outside intrusion needs to be ensured, which is a continuously evolving area of technological development.
As software comes out of the shadows and becomes a core and visible part of the equipment, its value also becomes more profound. Suddenly it becomes tangible, therefore a price tag becomes obvious. Not only a price tag for the initial purchase of the software, but also for keeping it up-to-date as long as it is in use. What would a computer with Windows 3.11 be nowadays, or an iPhone 12 running iOS 6?
Free? Yes free. In the consumer industry, there is a lot – truly a lot – of free software. Just browse the internet or the app stores of Apple and Google, and you find tons of freeware. One could argue it’s not truly freeware in the sense that the business model is different (e.g. driven by advertisement revenues), but many software makers do not make money out of their intellectual property. However, the tide is turning.
One of the largest scale freeware is the development language Java. Developed by Sun Microsystems, and released in 1995, it is now the most popular high-level programming language in the world. Although it got originally released under proprietary licenses, it got relicensed in 2007 under the GNU General Public License. However, recently, Oracle (who bought Sun Microsystems), has announced that future versions of Java will be again payable, upsetting the Java community. One can ask whether the move of Oracle is just, given the (short) history of free availability of one of the most powerful computer languages, including development kits, libraries, etc., but if we simply look at the value provided, a fee for its use is more than reasonable.
When we look at the app world, we can clearly distinguish 4 models: paid apps (either one time, or in the form of a subscription fee), free apps, with in-app sales (the goodies are behind the counter), or free apps that contain an advertisement for other products or services (hence, there is a business model behind it too). Then, we have a large category of apps, which come with other products (home automation apps, for instance, or the app to order your groceries) and services (for instance, government apps). Truly free apps (where no business model is identifiable) are rare and are becoming extinct.
The trend of paying for software is not a strange one. It happens as software becomes an integral part of our society, requiring constant levels of service (availability, reliability, data integrity, and security). This also implies the need to keep the software up-to-date, as the surrounding environment is also changing.
Visibility
Update policy
Past
Minimum
Occasional
Now
Core UI
Regular
Figure 1: Role of equipment related software, in the past and now
As software becomes visible and needs to be maintained over the equipment lifetime, a new question arises: what is the right pricing model? Often, the starting point is a continuation of old practices, which means in the equipment industry cost plus at best (if not for free). However, with software – after it has been developed – the cost of selling one unit more is immaterial (here we take the cost for maintaining the software separately), so a cost-plus model is highly theoretical. Therefore, it is logical to look at the value it provides. The more value, the higher the price tag. The value may come from functionality, user-friendliness, complexity it solves, level of automation, etcetera.
Another aspect of pricing is the number of users. The more users have access to the software, the more value it provides, as it delivers ‘its’ value to more people, easing their work, or providing the functionality they seek. In that sense, it scales nicely with the number of users.
Another way of looking at users is to look at how much equipment does the software 'manage'. Typically, the more units are under its reign, the more value it provides, as more business (e.g. throughput of product) is handled by the software.
A further aspect of value provision is the time of use: the longer the software is in use, the more value it provides. Therefore, a one-time initial cost does not align very well with the value the software provides. Therefore, a reflection of the period of use seems like a clear value driver as well.
A final aspect could be the actual use. The more intense the use is – e.g. the number of product(s) produced or handled using the software – the more value could be attributable to the software. Albeit true, in many cases this could be information not accessible to the producer of the software, or even seen as proprietary by the user.
Pro Contra No cost
Focus on equipment itself
Hidden cost, no transparency
Perpetual license
Simple, one time
Limited reflection of actual value
Pay per functionality
Close to the value perception
Different users may require different functionality
Pay per user
Simple, could be once or regular
User profiles could be very different, irregular users overpay
Pay per use period
Reflects actual use, hence the value
The granularity of use periods could be complex
Pay per use
Reflects best the actual use, hence the value
Complex, the information could be proprietary
Figure 2: Equipment software pricing models
In our view, free and premium software should be something of the past. Software that comes with equipment, providing clearly distinctive value, should be paid for. Preferably in a way that aligns to the value it provides. It could well be that the freemium model works: the base version of the software is free, but with increasing levels of automation, or other types of functionality, and as such a suitable pricing model should be applied.
For equipment manufacturers this implies two things. One: they must create an understandable and long-term viable business model for the software that comes with their equipment. Second: they must develop a software development and maintenance factory that is able to deliver constant high-quality software. The revenues from the software sales, and service level agreements should be enough to fund this software factory.