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

June 10th, 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:

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.

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:

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:

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

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

I hope that this manifesto can be helpful as a guide for building your own software. However, I don't intend to just post it bare. One of my top aspirations is to run a publishing house for software and other intellectual property where these guidelines are enforced for all software we publish. Alongside industry-standard quality assurance protocols, we would run rigorous tests to ensure that the software will continue to survive in conditions where we can no longer support it, such as running the software on machines that have malformed connections to the Internet. We would also ensure that our business models and procedures are such that we can safely leave out features that would require an Internet connection or other sources of fragility. Expect more about these plans and aspirations on this blog in the near future.

Copyright © 2022-2024, TheHans255. This work is licensed under the CA BY 4.0 license - permission is granted to share and adapt this content for personal and commercial use as long as credit is given to the creator.