An increasing trend for regular-computer and mobile operating systems is for them to be updated on a regular basis along the model of “software-as-a-service”.
With this model, the companies behind these operating systems will typically license the operating system with new hardware, but not require the user to pay to acquire newly-developed functionality. It is in conjunction with making sure that all bugs and security exploits are removed from the system.
A problem that has been found with this method of delivery is that it can be easy to over-promise and under-deliver as what Microsoft commonly does. This has shown up more so with the Fall Creator’s Update of Windows 10 where Microsoft removed Windows Timeline and Cloud-Powered Clipboard, two highly-promised features, from the feature list for that update.
What is underscored here is the frequency of major updates that add significant amounts of functionality to an operating system, along with calling out the promised improvements for these updates. Apple and Google implement a yearly cycle when it comes to delivering major operating-system updates that are about adding extra features while Microsoft undertakes this on a six-monthly basis.
The advantage of the long lead-time that Apple and Google run with is that they can deliver on their promises by writing in the code and subjecting it to a long debug and optimisation cycle including delivering it in publicly-available beta-test packages. This is conversant with Microsoft calling out features for a major functionality update and having to have all of them work to expectation by the time the update is considered “feature complete”.
But how can Microsoft and others who implement the short lead times for major functionality updates avoid the issue of over-promising? Here they could announce that some features are being destined for the upcoming functionality update while others are being destined for the subsequent update.
Similarly, they could deliver the functionality in an “out-of-band” form such as free-to-install apps provided through the platform’s app store, a practice Google is undertaking with the Android platform. In the case of functionality dependent on a particular peripheral class, it may be delivered as part of the onboarding process that the operating system performs when that peripheral is connected for the first time.
Personally, I would like to see some effort put towards fine-tuning the peripheral and network interface software code to encourage more “driver-free” peripheral connectivity that occurs in a secure stable manner to the latest specifications for that device class.
What is being highlighted here is the risk of over-promising and under-delivering when it comes to delivering major functionality updates for an operating system.