Market First, Product Second: How to Validate Before You Build
9 January 2026
Contact Info
- Lilongwe, Malawi
- +265 899 25 21 95 (Whatsapp)
- contact@webmobyle.com
- Working Days: Monday - Friday
People First Building Web Applications & Systems for Growth | Request Quote
- Work Days: Monday - Friday
- +265 899 25 21 95
Inherent Risk of Reliance On Software Packages
Inherent Risk of Reliance On Software Packages
Download Audio: 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 it.
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 titled, 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 web and mobile apps, I bring together many software components, which in turn themselves use other components from other sources to build the necessary functionality. This is even more so in an Open Source Software project.
The chain of interlinked software is so prevalent, that there are special tools in many software development environments, that are designed to specifically manage dependencies. One example of such a tool is the Node Package Manager (NPM) in Javascript.
The software package dependencies can be so intricate, such 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 a project is no longer maintained. This can present a big headache. Naturally this means that you have to drop the dependency and find an alternative.
Finding an alternative can be simple sometimes: 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.
As dire as it is, the worst case scenario is that 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 all 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 to mitigate these risks, is to choose a stable and popular framework to work with. Frameworks are the major software package ecosystems, in which a developer will work. 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 its repository, such as GitHub or NPM, for example.
Regular and recent updates are also a good indicator as to whether a package has good sustainable prospects. A developer can avoid packages that have occasional update histories or have not been updated for months, when choosing software packages to use in a project.
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: to use a pun.
Want to hear some more from the Webmobyle Blog? Please
Prev Post
https://webmobyle.com/wp-content/uploads/speaker/Inherent%20Risk%20of%20Reliance%20On%20Software%20Packages.mp3?cb=1756319512.mp3 Download Audio: Inherent Risk of Reliance On ...
Next Post
Leave A Comment