Modern operating systems offer options for exchanging data between programs, but these opportunities are often low-level and exist at the implementation details level rather than in the application domain. Basics such as files, locks, pipes, mutexes, sockets, shared memory, etc. make it possible for programs to interact, but both interacting programs need to be modified. It is too complicated to connect all programs available on a computer or in the network. It is easy to calculate that in order to integrate two programs you need to make two edits, while integrating ten programs would require 90 edits in total.
The popular way of extending programs’ capabilities is by using plug-ins. However, plug-ins are usually written for specific versions of specific programs, but their functionality can be required by similar solutions. For example, there is a plug-in for Mozilla Thunderbird email client that displays a warning if the user attempts to send a message to a corporate domain using a personal email address. This feature would be useful for any other email client, but due to API incompatibility, its applicability is limited.
It is not uncommon for a program to interact with another one by reading configuration files or registry entries created by it. This results in a dependency between the versions of these programs (through the format and path). For example, when a new version of Microsoft Visual Studio comes out, Cmake should be upgraded, otherwise it would not be able to use the new version of the compiler. On Linux-based systems, this approach often causes disaster when one program generates a configuration for another program; it is very difficult to trace the chain back without specific expertise.
Cross-process and cross-window interaction also depend on the programs used. Network interaction requires a specific protocol, and protocols developed for similar tasks often differ.
Sivelkiria proposes to avoid adding compatibility features retrospectively. Instead, all programs can be based on the same concepts. Instead of creating a dictionary for each pair of languages, you can initially agree to use a common, evolving dialect (without limiting the technology and programming languages used). In this case, any video recording program will be compatible with any camera model and stream format simply by definition, including support for network cameras, without any additional effort on the part of the developer. A plug-in that solves a specific task (e.g. adding a mail processing method) will be compatible with any mail client. The system administrator will not have to choose a solution based on the features it supports, since all solutions support any extensions and mail handlers simply by design. The operating system is responsible for removing differences between program versions during the interaction, and the interaction itself is conducted for specific data types rather than for specific programs.