Future-proof technology is [technology](technology.md) that is very likely to stay functional for a very long time with minimal to no [maintenance](maintenance.md), even considering significant changes in state of technology in society. In a world of relatively complex technology, such as that of [computers](computer.md), this feature is generally pretty hard to achieve; today's [consumerist](consumerism.md) society makes the situation even much worse by focusing on immediate profit without long-term planning and by implementing things such as [bloat](bloat.md), intentional introduction of complexity, [obscurity](obscurity.md), [dependencies](dependency.md) and [planned obsolescence](planned_obsolescence.md). But with good approach, such as that of [LRS](lrs.md), it is very possible to achieve.
A [truly good technology](lrs.md) is trying to be future-proof because this saves us the great cost of maintenance and reinventing wheels and it gives its users comfort and safety; users of future-proof technology know they can build upon it without fearing it will suddenly break.
- [Free (as in freedom) software](free_software.md) -- making your source code available, legally modifyable and shareable is a basic step towards making it easy to repair, backup and adopt to new technology (e.g. compile for new CPU architectures etc.).
- Building on top of already well established, time-tested and relatively [simple](kiss.md) technology such as the [C language](c.md) or [comun](comun.md). Choosing to use the older standards with fewer features helps greatly as the less-feature-rich versions of languages are always more supported (for example there is many more C89 compilers than C17 compilers) and can even be relatively simply reimplemented if needed. Another example is e.g. [OpenGL](opengl.md) -- you should use the oldest (simplest) version you can to make a program better future proof.
- Minimizing [dependencies](dependency.md) to absolute bare minimum and offering alternatives and [fallbacks](fallback.md) in cases where you can't avoid introducing a dependency (e.g. you should always offer an option for [software rendering](software_rendering.md) in any program that by default uses [GPU](gpu.md) for 3D graphics). Dependencies are likely the single greatest cause of software death because if one of your dependencies dies, you whole project dies, and this goes [recursively](recursion.md) for all of the dependencies of the dependencies etc. This usually means software [libraries](library.md) but also goes for other software such as [build systems](build_system.md) and also [hardware](hardware.md) dependencies such as requiring GPU, floating point, special instructions etc.
- Practicing [minimalism](minimalism.md) and reducing complexity which minimizes the maintenance cost and therefore raises the probability of someone being able to fix any issues that arise over time. Minimalism is necessary and EXTREMELY important, [bloat](bloat.md) will make your program very prone to dying as it will depend on a big community of programmers that maintain it and such community will itself always be very prone to disappearing (internals disagreements, stopped funding, lose of interest, ...).
- Making your program [portable](portability.md) -- this ensures your program can be adapted to new platforms and also that you use abstractions that untie you from things such as hardware dependencies.
- Generally just avoiding the hyped "modern" "feature-rich" ([bloated](bloat.md)) technology arising from the consumerist market.
