Making Software That Will Outlive You: A Manifesto

In which the author lays out principles for building software that will continue to be useful long beyond the period you are able to support or publish it.

By: TheHans255

6/9/2024

I believe that software should, generally, remain useful after the company developing or publishing it is no longer able to keep up the work. Whenever I download software for one of my machines, I prefer something that I know I'll be able to use for years to come, even if it takes more work on my end to support, and not have to worry about losing my software to hardware failures or to servers not staying online. In a world where this is increasingly not the case, where companies such as Ubisoft even go as far as to actively take away copies of software they no longer sell, I want to present a list of principles that consumers can use to look for software that will continue to function, and that developers can use, should they so choose to work with their business model, to make good on that promise to their users.

Of course, I understand that not all software business models can work with software designed like this, such as software that is largely tied to a real-world, ephemeral event, or if some restrictions are required in order to ensure that your software's developers get paid. However, I believe that if a developer's business model works with making their software outlive them, they should, and I also know how easy it is for a developer intending to do this to add a feature that seems harmless now, but will become a fatal error when their services eventually shut down.

1. Software Distribution

It should be possible to obtain the software in a digital file format that can be legally saved and loaded from a standard digital mass storage device, such as a Serial ATA (SATA), NVM Express (NVMe), USB mass storage drive, or SD Card formatted in FAT32, NTFS, or EXT4.

It should be possible to copy that file perfectly, with no information loss, to another mass storage device.

It should be possible for any user in possession of a mass storage device with this file, regardless of whether or not they are or are affiliated with the original author of that file, to load that file onto a compatible computing device that they own and bring the software to full functionality.

It should be possible to repeat the above two processes any number of times while expending no additional resources.

2. Software Dependencies

Most software will require dependencies on other software to run, such as the language runtime, the build toolchain (for programs distributed as source), and supporting libraries. In order for a piece of software to abide by this manifesto, all of these dependencies must as well.

3. Choice of Platform/Hardware

The software should be built for a platform where it is possible, legal, and with the overall (not case-by-case) blessing of any relevant platform owners, to install software contained on an offline mass storage device.

The hardware platform that the software is run on should either be available as an open specification that can be reimplemented by competing manufacturers, or should be possible and legal to emulate on such hardware.

Any firmware or operating system that the software relies on when running on the platform should also abide by the principles of this manifesto.

4. Server Dependencies and Online Communication

Software should avoid contacting an Internet service to authenticate ownership, either in full or in part. It should be possible for the software to continue to function, even at a reduced, "offline" level, if it cannot reach the authentication service (either because the user is not connected to the Internet, or the server no longer exists).

If the software has any non-core functionality that involves communicating with a remote server (such as telemetry or leaderboards), it should be possible to disable that functionality at no detriment to the rest of the software.

If the software does have any core functionality that involves communicating with a remote server (e.g. online gaming, file sharing, or social networking - that is, a reason to use the software for which communicating with another device is expressly the point and does not make sense without it), then one of the following should be possible:

• The user should be able to clearly and prominently select their own server to connect to. This means that the server software should also be available to users, adhering to the same principles in this manifesto (including dependencies on any services they may connect to).
  • Note that this includes all servers the software connects to. If, for instance, the software can retrieve a list of servers for primary functionality, the server hosting the server list itself must also be able to be specified by the user.
• The user should be able to use the same functionality over LAN with one or more copies of the same software.

If the software connects to any blockchain services, then not only should the user be able to specify their blockchain RPC endpoints (and hence the chain they are running on, including a test/private chain) but also be able to specify the addresses and smart contracts they wish to interact with, as long as they expose the same interface.

5. Legal Requirements and Intellectual Property

It must be possible and legal to possess and use a copy of the software perpetually in at least one jurasdiction, after all necessary payments (outlined at first sale of the software and at no time afterward) have been made.

It must not be a requirement of the software to pay via a recurring subscription - the option should always be provided to use the same version of the software perpetually after paying a one-time fee. It must also not be a requirement that the software stops working after a certain date, whether determined by an Internet service or the system's internal clock, unless another version of the software is available that does not have this restriction.

Any intellectual property (IP) contained in the software must be used with a legal agreement with all of the relevant IP owners that the software can exist perpetually with that IP being featured, according to the conditions under which the software is being distributed and/or sold, even if the software is not going to be published perpetually. This includes characters, scenarios, logos, designs, soundtracks, and other relevant trademarked, copyrighted, and patented material.

• If there is any expectation that the software will be delisted after several years due to its intellectual property grants expiring, or if an update will be made that removes the intellectual property in question, it should still be possible and legal to use a version of the software published before this event, even if no new copies of that version are published.
• Any "bootleg" software that uses intellectual property illegally without the express or implied permission of the rights holders does not abide by the manifesto, unless it falls under the doctrine of "fair use".

The functionality of the software itself should be legal in the jurasdictions in which it is being used, including all relevant privacy and information protection laws. (The author notes here that although illegal software violates the manifesto, the correct resolution may also include a revision of the laws in question, and not necessarily a change to the software itself. The author also condemns the efforts of authoritarian jurasdictions - their own included - to subjugate their legal preferences and morals onto other jurasdictions.)

6. Ports

As long as at least one version of your software follows all principles in this manifesto, it is permissible to publish ports of that software to other platforms where not all principles can be followed (such as platforms that do not allow you to install from a mass storage device or specify alternate servers).

These ports must not contain any major content or functionality that could not also be made available on a port that does follow all principles in the manifesto.

These ports should not be the primary source of the software's revenue. If the software developer wishes to commit to supplying software that will outlive it, it should maintain a viable business reason for doing so.

What Is Not Required

The following principles, while preferable for the longevity and preservation of software, are not required for it:

• Free and Open Source Software: Having the source code for software available greatly assists its longevity, as users can ensure that it can be ported to other platforms as the original platforms age. However, a closed-source binary can still be preserved on its target hardware for many years as long as it can work offline or with flexible online requirements, and can be preserved beyond that with software emulation and compatibility layers (though these must also abide by the manifesto). In addition, relying on keeping your code open source means that you must ensure that all of your build tools abide by the manifesto as well, which is not a requirement for distributed binaries.
• Hardware Emulation: Being able to fully emulate the hardware the software runs on greatly assists its longevity, as aging hardware can be replaced with an emulated counterpart on hardware in better condition. However, if the hardware is based on open standards, or it is possible to port the software to run natively on other hardware, then emulation is not necessarily required.
• Full Offline Functionality: As outlined above, some software has core functionality that requires it to communicate with a wider group of devices in order to make sense, such as social networking apps. Some software might also require offloading functionality to a server in order for the client to run on the target device. The requirement is instead to either allow the software to work over LAN with a symmetric copy of the software, or for the user to be able to specify which server they want to use and for the server software to be available according to the principles of the manifesto.
  • However, if the software is based on a binary and expected to run on a specific version of a platform, this requirement becomes more necessary, as users of the software will eventually need to avoid connecting to the Internet in order to remain safe. This does not, however, restrict LAN usage.

A Closer Look at Platforms

Below are some examples of platforms and their ability to follow the principles in this manifesto. This list is not meant to be exhaustive, and it is always possible (if only legally) to create software that violates the manifesto on these platforms, but it can serve as a starting point when choosing platforms for building or finding long-lived software.

The following software platforms are capable of adhering perfectly to the manifesto:

• Most Linux distributions. Linux ELF (Executable and Linkable Format) executables and libraries can be run from any ordinary file storage device, and the core toolchains for building these executables are available through the GNU General Public License or other open source licenses, thus making them available for a wide variety of computing platforms.
• Any version of Android that can be downloaded as a disk image and flashed to a device's internal storage. Android allows you to enter "developer mode" by tapping on the version number in the options several times, which then allows you to sideload APK executable files from a mass storage device.
• HTML5 (or, more specifically, any specific web browser or version of that web browser that adheres to this manifesto). HTML5 applications are designed under open standards, so as long as identical source/binary executables can be sourced, the applications themselves can be made to work indefinitely.
  • Note that this only applies to the HTML5 client. HTML5 also necessitates a server written in a different platform, and this server must also abide for the manifesto in order for the client to do so. (The server can be a simple static file server, though, of which plenty of manifesto-abiding options exist.)
• Many other scripting/bytecode application platforms that run on top of other platforms, especially if they do not make use of underlying binaries. These include Java (via OpenJDK), Python, Perl, PHP, C# (via .NET Core/Roslyn), Node.js, and more (though note that the application platform must itself adhere to the manifesto).
• Any fully emulatable platform for which all the intellectual property can be legally represented. For instance, programs developed for MS-DOS can perfectly adhere to the manifesto because the x86 computers that DOS ran on can be well emulated on modern systems, and FreeDOS exists as an open-source OS compatible with MS-DOS.

The following software platforms have some limitations that prevent any software on them from fully abiding by the manifesto:

• All modern home consoles, including the Xbox Series S/X, Playstation 5, and Nintendo Switch. All official software published for these consoles is licensed only for use on those consoles and cannot be legally distributed in other ways, and all of these consoles require hardware exploits in order to run unofficial software on them. These consoles also heavily manage the way the Internet is used, requiring subscriptions for online play, and thus cannot allow players to select their own servers to connect to (though they can still allow LAN play).
• iOS/iPadOS. These operating systems can only run on official iPhone and iPad hardware, which has a finite useful life and can only be obtained from and serviced by Apple. In addition, most software can only be downloaded from the official App Store (also tightly controlled by Apple), and sideloading applications on the phone requires an Apple Developer License (which, too, is tightly controlled by Apple and requires a $99 USD/year subscription).
  • However, because Apple devices have unique UI conventions (such as the lack of a hardware Back button) and native features (such as the AirDrop protocol) not shared with other devices, the author would consider it permissible for an iOS port of an otherwise manifesto-abiding application to adapt to iOS's UI conventions and use its features.
• Cloud-only platforms, such as Xbox Cloud Gaming or Amazon Luna - all binaries are kept internal to the cloud service, and new ones cannot be loaded. Plus the more obvious issue that the attached cloud games will be unavailable should the service either shut down or simply choose not to support them. (Of course, if you have software on a cloud platform, releasing the software for a home platform is usually not hard.)

The following software platforms have some caveats, but can be made to adhere perfectly to these conditions assuming working hardware:

• Most versions of Windows. The Windows operating system itself has some caveats - specifically, Windows itself must be activated via an Internet or telephone service - but can run fully offline once activated, and the Windows PE format can be run from any ordinary file storage device. Most Windows programs can also run perfectly under the Wine or Proton compatibility layers on Linux or macOS.
• macOS. The activation requirements go harder with macOS than with Windows, as running macOS legally requires using Mac hardware with a finite support lifetime and only slightly longer practical lifetime. However, once you have a working macOS installation, applications can be loaded from any ordinary file storage and copied to the Applications folder (though you'll have to click through the scary warning first if the app isn't signed with an developer license).
• Most older video game consoles. As with modern home consoles, the official software released for these was typically only permitted to be used on those consoles, and the legal grounds about releasing your own software for those platforms is iffy. However, the simpler design of these consoles allows them to be easily emulated, and developing your own software to run on these emulators is nearly always legal. (The rightsholders themselves also often use emulation to re-release these older titles.)