Inherent Risk of Reliance On Software Packages
This week, I completed a series of updates for a client's web app and a major headache of the process was discovering that a vendor for one of the software packages used in the app has abandoned it.
When a vendor abandons a software package, it means that they are no longer maintaining it. An unmaintained software package opens up an app to all manner of risk because it means that there are no longer crucial security updates to the package.
It's not just the security risk that is associated with an unmaintained software package, it also means that new features and improvements for the software package will no longer be forthcoming. The long and short of it is that unmaintained software packages can no longer be updated.
For the reasons mentioned above and many more, it is crucial to keep software up-to-date. The blog post Keeping Software Up-To-Date, discusses at length why it is important to keep software up-to-date.
Reliance On Software Packages
It is rare or maybe unheard of to find software that contains only packages from one vendor. Every piece of software out there is made up of components that come from different sources. That is just how software is built.
Typically when I build my web and mobile apps, I bring together many software components which in turn use other components in themselves to build the necessary functionality. This is even more so in an Open Source Software project.
The software package dependencies can be so intricate that managing them manually would be nothing short of a nightmare and tools like NPM automate the process of software package management instead of developers having to do it manually.
When A Software Package Is Abandoned
It can be frustrating when a component used in the project is no longer maintained. This can present a headache. Naturally this means that you have to drop the dependency and find an alternative.
Finding an alternative can be simple; in which case you simply swap out the abandoned software package. At times it is not so simple; in which case you might have to restructure a significant portion of your app.
Although dire, you might fail to find an alternative software package. What do you do then, in such a scenario? You might consider developing your own package but may not have the resources to do so and may have to drop the feature altogether.
What if the feature is critical and dropping it is not an option? Keeping the status quo by doing nothing is not an option either. Due to the intricate chain of software package dependencies I mentioned earlier, you might find that having an outdated software package version can prevent you from updating the entire app.
The nature of software package dependencies is such that very old and outdated packages dependencies will prevent you from taking a forward path in some updates until those outdated packages are updated. This is why it is important to make sure that you preemptively have options when developing an app.
Creating Options For Flexibility
Mitigating risk is a business every software developer has to be heavily invested in. You have to be prepared for eventualities such as one of the software packages you depend on being abandoned.
I know. This sounds daunting. After all, being a developer does not include the skill of being able to predict the future. However, by being vigilant, it is possible to create options for flexibility and sustainability.
One of the things a software developer can do is to choose a stable and popular framework to work with. Frameworks are the major software package ecosystems in which a developer will work in. By working with a widely popular framework, you reduce the likelihood that the framework itself will get abandoned.
Popularity is also a good measure for a reliable package to use within a framework. The more popular a software package is, the less likely it will get abandoned. You can gauge the popularity of a package from their GitHub or NPM Web page for example.
Also important is to do your due diligence as a developer by checking out whether a software package has a good alternative you can use incase your first choice gets abandoned. That way, you can ensure that you will never be caught with your pants down.