There are many different approaches to sustainability. The way that you approach sustainability will depend on many factors, such as how important is the software, how mature is it, what is the size of its community and what resources available for achieving sustainability? Here is our breakdown of the different approaches to achieving software sustainability.
Technical preservation (techno-centric)
Software is reliant on hardware, and hardware changes when each new model is released. Over time, hardware will change to such an extent that older software will not run on the latest hardware. Without the hardware to run on, software becomes redundant.
The easiest way to ensure that there will always be hardware on which to run your software, is to preserve the hardware (and its operating system and any other reliant software). Technical preservation has one big benefit: it’s easy. You simply continue business as usual. There are drawbacks to this approach. The first is maintenance. Over time, hardware components will wear out and must be replaced. If the hardware is no longer manufactured, components become scare and expensive. Ultimately, you may find yourself with broken hardware and no way of fixing it – leaving you with redundant software. The second drawback is isolation. If your software only works with very specific hardware, you limit your users to those people with the right hardware. This could be a very small group.
Technical preservation is a straightforward approach to sustainability, but it’s only reliable whilst you have a stockpile of spare parts.
You want to keep your software, but you’re worried that technical preservation might leave you with no hardware or an expensive maintenance bill. The alternative may be emulation. An emulator is a software package that mimics your old hardware (and, possibly, your operating environment) so that it can be run on any computer.
Emulation gives you the flexibility to run your software on new hardware, which gives your software a new lease of life. As always, there are drawbacks. You need to find an emulator. You might be lucky and find one available under a free-to-use licence, or you might be able to buy one. However, if your old hardware was rare, you may find that no emulator exists. In this case, you either have to write an emulator yourself, which requires specialist skills and could be expensive, or explore another of the sustainability approaches. It is difficult to write an emulator that perfectly mimics the old hardware. This can lead to differences between the operation of the old hardware and the new emulator, which could manifest themselves in annoying quirks or more serious problems.
Emulation allows you to keep your old software, but requires the existence (or in-house development) of a reliable emulator. It also adds a dependence on the emulation software, which - like any other software - could itself become obsolete.
If you need to reliably reproduce the operation of your software, the best choice may be migration. With this approach, you re-code your software so that it will work on new hardware or operate with new and reliable software. Re-coding for migration also gives you the perfect opportunity to enhance your software’s operation by fixing bugs or adding new features.
There are many migration approaches. They range from a complete re-write of the code, which allows your software to be used on a completely different system, to continual migration, which keeps your code up to date with the latest (generally small and continual) changes to the hardware and software that your code relies on.
A complete migration to a new system is the same as writing new software – possibly harder because you are constrained by the old architecture. This leads to migration’s biggest drawback: it’s resource heavy. It depends on the complexity of your old software, but migration might need the investment of a significant amount of time.
At some point in its lifetime, most code will be subject to a change in the hardware and software that it relies on. For example, your code might need to be tweaked to use a new version of Java or the latest version of an operating system. This is partial migration.
Migrating your software completely produces a new software package that reliably reproduces the operation of the old software, but it could require a significant investment of resources. Continuous migration is a less arduous task than complete migration, and is generally necessary if your code is to stay in use over a long period of time.
Sustainability requires the investment of resources. Cultivation is one of the best ways of sharing the responsibility for these resources. Cultivation is the process of opening development of your software. This is where you allow developers access to your code – under a licence – so that they can work with you. The deal is that outside developers get access to your code so that they can adapt your software to meet their exact needs, but any bugs they fix or new functionality they add is given back to your project.
Cultivation allows more contributors to be brought into your project, which helps share the sustainability workload. Apart from having more people to work on the code, a larger group of developers means that knowledge about your software is more widely distributed. This means that the departure of one developer is less likely to have a catastrophic affect on your software’s future.
Cultivation’s main drawback is that it’s a long-term process. Cultivation is not suitable as a quick fix to ensure sustainability in the short term; it requires effort and planning over many months and years. Cultivating an open-development community is not as simple as making your source code publicly available. You also need to invest time into building your community, which requires work to understand what your community wants and how to appeal to them. The goal is to build a community that is self-sustaining so that the future of your software is assured.
Cultivation promises a self-sustaining community of developers who work together to keep your software up to date, but requires work to cultivate the right community for your software.
Rather than sustaining your software in an operational state, you could choose to hibernate it. Hibernation could be the right approach to follow when your software has come to the end of its useful life, but there is the possibility that the software might need to be resurrected to double-check analysis or prove a result. Alternatively, there may not be a user community for your software, but you believe one will occur in the future. Hibernation allows you to preserve the knowledge about your software so that it can be easily resurrected in the future.
Hibernation can be a one-off process. Unlike sustainability, which requires a continuous investment of resources, the hibernation process can have a beginning and – importantly – an end. Preparing software for hibernation can be resource heavy, and if the software is never resurrected you may feel that those resources were wasted.
Hibernation allows you to store software that you do not currently need, but it requires a significant – if short lived – investment of resources.
If software lacks a community, the resources to continue or a developer, then the only alternative might be deprecation. All effort invested into the software comes to an end, but, unlike hibernation, no effort is invested in preparing the software beforehand. In the future, if someone wants to use the software, they may not be able to find a stored copy and it might be expensive or impossible to resurrect the software.
Deprecation is easy to perform, but often marks the end of a software package’s life and is typically only chosen when no other option is available.
“Never put off until tomorrow that which can be done the day after tomorrow... or the next day”.
Procrastination is certainly the easiest of all the sustainability approaches, but things rarely turn out for the best when left to their own devices – and that applies to software too.