The jing-jang of hardware and software support

Ever since the 1980s, a vicious cycle of software and hardware requirements and updates has ‘plagued’ users and maintained high and constant rents to the vendors who systematically collude to render their previous offerings obsolete, while forcing (not enticing) their customers to upgrade to the latest incarnation of their products.

The justification for this form of planned obsolescence has — invariably — involved mention of changing standards, APIs, market and technical requirements, certifications and so on. Perfectly good products have time and again been condemned to retirement only because their manufacturer deemed it uneconomical to maintain support for them.

During the late 1990s and early 2010s, the open source community did much to reverse this process, with varying results. Open source drivers, initially developed by individuals and, later, by small companies aiming to attract revenue from disgruntled users that wanted to preserve their investment in hardware devices, proved that the ‘market’ and ‘economics’ arguments were invalid at best (and deeply hypocritical at worst). Some OEMs quickly embraced open source, providing access to their device driver source code; others maintained a binary blob. Others, when their positioning afforded them the option, maintained their limited support policy.

Sadly the allure of SaaS and cloud-based solutions, the gradual conversion of personal computing equipment to ‘appliances’, both through the proliferation of Android and iOS-based devices, through the integration of erstwhile external components (sound cards, networking, I/O interfaces) and the inevitable demotion of activities previously requiring support for device interconnection (printing is an example), has led to the apparent sidelining of this issue, by both consumers and regulators.

There are many major vendors guilty of this. Canon, who limits support to printers and scanners only a few years after they are released. Native Instruments, who ceases to support hardware devices only a mere 5-6 years post release, citing changing APIs in Windows or macOS, even though those devices are extremely simplistic (the Rig Kontrol 2 and 3 are good examples here) and the community might be able to keep providing support for them for years, had the company released the specifications for writing a device driver. Apple and Microsoft itself, the former removing new features when their software runs on older devices, even though said devices were perfectly adequate, the latter requiring the use of a new CPU to run the latest version of Windows 10, again for no good reason.

This type of behaviour, along with vendor lock in, constitutes rent-seeking and is harmful, for all the reasons rent-seeking is harmful, both to the economy, consumers, the environment and competition.
And this is one case where regulators should step in. In the EU the warranty for defects is mandated to be at least 2 years. But there is no mention of support periods for dependent products. Regulators require either longer term support for products sold (explicitly setting minimum terms to the pre-sale specifications put forth by the vendor) or opening up of full, detailed specifications for all parts, components or mechanisms involved in the product(s) involved to the public at no cost for the community (or competitors) to maintain.

As long as the operating framework remains unchanged there is little to no incentive for any vendor to change their ways and start supporting their devices for the long haul.