The reader may get the impression that this article is fighting windmills, trying to find faults where everything is okay. Unfortunately, all the problems described above are demonstrably real because they lead to wasting users’ and developers’ efforts and resources. This will be illustrated in this chapter.
It wouldn’t be far off the mark to say that qualitative changes in users’ hardware and its functions occur very rarely. Modern smartphones still bear similarities to their predecessors, the angular mobile radio phones, though the technical features and software installed in these devices have evolved significantly since then. Professional devices (medical equipment, cameras, etc.) become more compact and powerful; however, real breakthroughs are rare as well. Desktop computers, despite the rapid performance advancement, have not changed much in appearance over the past 30 years. The concepts of wearable devices (glasses, watches, etc.) were actively used in spy films in the mid twentieth century. Finally, smartwear, mobile communication devices, virtual assistants, etc. are well-known from ancient fairy tales.
Similarly, the user’s needs haven’t changed much over time: The needs for the message exchange, for making the calls, for working with documents, for creating and viewing multimedia, for playing and for calculations preceded the appearance of modern digital products (and in a sense defined their development). However, try to remember how many times you had to change (for free or not) the software you used (e.g. messengers, office software, photo editors, media players, etc.) just to make it fit the current situation, without gaining anything principally new with these changes.
The software evolution is much more rapid than the hardware evolution, which is due to the ease of replacing the software without changing the device. This development speed would suggest that by now all the problems we have discussed would have been resolved, and the users’ capabilities would have been expanding each day. The fact that this is not happening suggests that something is wrong here.
Each new platform or platform family (e.g. Windows, COM, Web, ActiveX, Java, .Net, mobile devices, cloud services, application markets) gives us a hope that the ways of using and developing software will be simplified. But in practice, it turns out that changing the platform only means that the user has to pay again for a not-so-new solution wrapped into a different cover and featuring some insignificant improvements.
After paying for a new device and for the software to run it, the user soon finds out that it’s time to upgrade both of them, even if their needs haven’t changed. New versions of programs work too slowly with old hardware, and sometimes even the device itself has its performance lowered (e.g. Apple iPhone battery controversy).
Another example is gaming hardware: despite the fact that most games keep to the same old concepts of shooters and arcades and really groundbreaking technologies, such as ‘Living World’ or AI NPCs, remain the domain of fanatics, visual changes force gamers to buy more and more powerful hardware.
The next good example would be document automation systems: at the beginning, they were supposed to save effort and paper, but the ease of creating new forms often leads to higher costs.
There is a good description of this problem given by the British author, Terry Pratchett, in one of his comic novels. According to the creator of Discworld, ‘a really good pair of leather boots cost fifty dollars. But an affordable pair of boots, which were sort of OK for a season or two and then leaked like hell when the cardboard gave out, cost about ten dollars. A man who could afford fifty dollars had a pair of boots that’d still be keeping his feet dry in ten years’ time, while the poor man who could only afford cheap boots would have spent a hundred dollars on boots in the same time and would still have wet feet.’ In this example, it’s easy to see who profits from this situation.
There is an obvious conflict of interests between software publishers and users. The former are interested in making their product as short-lived as possible and the latter would prefer to buy each feature just once. Alas, the curse of in-built obsolescence impacts the IT industry perhaps even harder than any other branch of economics!
Can Sivelkiria propose a way of fixing things, or is it just another platform fighting for its own corner of the market? We will now show that Sivelkiria has some features that make it cheaper and potentially more attractive for the user.
First, the open design of all available programs makes it possible to replace any module with a cheaper alternative without losing functionality, or at least with full understanding of the features that will be lost. No module can do anything it is not supposed to, which means that a third-party module is guaranteed to do the same job as the original one (although perhaps with a less convenient interface, fewer features or slower performance). Having tests and other ways of supporting specific operations performed by a specific module can minimize potential damage: the modules that use the one being replaced provide information on what features they require, so that the operating system can decide whether the option can be used.
Second, the fact that a product is reaching the end of its life doesn’t necessarily make its use dangerous. The components that are really vulnerable (e.g., network protocols implementations or potentially dangerous file format readers) can be replaced with the ones still being supported without losing the solution’s functionality. The GUI part can be updated or replaced, if required. When it comes to the modules which implement business logic, continuing to use them after the support expiration date is unlikely to lead to security breaches, since the operating system guarantees that they cannot be used in any unexpected way. The design defined by data interfaces and module prototypes is built specifically to isolate potentially dangerous code as much as possible.
Next, in Sivelkiria there is no black box: all programs consist of modules that work with compatible data types. This means that software developed 20 years ago will still be compatible with modern programs and capable of exchanging data and calls with them, because the OS support team ensures interface compatibility. Thus, using an outdated component in the infrastructure won’t prevent data exchange with newer systems: they won’t be able to detect the source of the data and any attempt to block the data based on its origin is a violation of the terms of cooperation and leads to certain consequences, including the blocking of the module until the problem is resolved and subsequent financial losses.
Finally, Sivelkiria’s modular structure makes it possible to use the ‘Support your product or let someone else do it’ model: if the module stops updating and officially becomes ‘legacy’, it can become public property provided the publisher agrees to the conditions which are incorporated in the terms of cooperation. Even if this does not happen, the specification available for each module prototype allows third-party developers to prepare a replacement.
Obviously, none of the above prevents users from using the most up-to-date versions of the software if they want to.
These conditions may seem too harsh for software publishers, and to some extent, this is true. However, we believe it is too early to fear that they might boycott the platform. In a capitalist economy, each company’s actions are defined by the profit-and-loss balance. When a company discovers that losing the new platform’s users impacts its business, it will accept these conditions, especially if there are alternative solutions available.