Don’t blindly use Third-Party Dependencies

Avoiding spending time and effort solving problems that others have already solved can be used to achieve high speed, low cost and quality in software development. The most common way of putting this principle into practice is by using third-party libraries. Third party libraries play a big role in software development as they cover a broad spectrum of functionalities.

Using third-party libraries gives a set of advantages in development, but it must be noted that for the projects used third-party libraries to be successful, proper understanding and planning must first occur. Most developers add third-party libraries to products without going through proper research and without understanding the requirements, associated risk, and maintenance needs etc. Not having a proper understanding of above mentioned facts, your product can end up in a mess.

Sometimes it is very hard and tricky to decide when and whether to use third party libraries in your project. Before adding any library, it is very useful to do a research on the library, make an analysis of your project and the environment you are working in. In this article, I’ll give some facts you should know and follow before and after adding third-party libraries to your product. Before going through this article, If you don’t have clear idea about third-party libraries and their key advantages & disadvantages, please refer to the my first blog on third party dependencies.

When to use

Lack of competency, lack of resources and tight timeline are some of main reasons to use third-party libraries. How much time is allocated for implementation? How many developers will be working on the project? Lack of domain expertise needed for the requirement within the team. If your team has a few developers, a tight timeline and less domain knowledge for the requirement, adding an existing third-party library for the functionality saves your team from all above mentioned aspects.

Please consider the following facts also when using third-party libraries for your product.

• Is it a core or non-core feature?
• How important is this feature for my application?
• If it’s a non-core feature, how often will it be used?

When using a third-party solution, you’re inevitably dependent on the provider. If the product’s core features and commonly used non-core features depend on an external party, this poses a risk to the stability of your software. You should retain full control over the code of your core features. Libraries typically make trade-offs in order to be able to cover a wide spectrum of use-cases. By using libraries for your core features you are making these very same trade-offs. You must aware of this risk and should take decisions considering every aspects or should have a plan B.

Factors to consider when adding third-party dependencies

Does the library meet your specific requirements?

If the library doesn’t meet all of your requirements, you may have to modify it (which will take extra time) or use it in a way that it wasn’t designed for. Keep searching until you discover the appropriate library, or, in the worst-case scenario, write your own!

Popularity of the library

Search the web to find recommendations for commonly used libraries. Check how many contributors and stars does the library have and how many bugs and issues has it reported. More contributors and good feedback increase the chances that the bugs will be fixed in a reasonable time frame and the library will continue to be actively maintained.

How reliable is the vendor?

You can reduce the chance of being stuck with a buggy or abandoned library by conducting a background check on the author. Are they active on Github? Are they responsive to issues, bug fixes, and accept pull requests? When was the library last updated? If it was last updated several years ago, there’s a good chance it was written in an unsupported version or doesn’t support the most recent version of your preferred programming language.

If a library’s author is actively supporting it, it’s a good sign that it’ll be stable in the long run, despite platform and framework modifications.

Quality of documentation

Is the library well documented? If the documentation is not good and you have to spend more time discovering how to use the library than it would take you to implement functionality by yourself, then it is obviously not a good choice.

Test coverage

If a library has very few or no tests, how can you be sure that it will do what you are expecting it to do and that you won´t encounter critical bugs when integrating it into your project?It´s really bad to have a bug on your application because of a bug on a third-party library.

Good test coverage can also indicate that the developer is concerned about the software’s quality and maintainability.

Pricing and licensing terms analysis

You need to evaluate third-party software from the cost perspective. Conduct a pricing analysis to determine which platforms best fit your budget.

Also, analyze the licensing terms — especially regarding the scale. Consider what would happen in case of the dynamic growth of your user base.

Analyze project threats

When deciding on a third-party solution, examine what level of security it offers, what its data management policy is, and compliance with regulations such as GDPR.

You’re adding a dependence to your project, but it’ll almost certainly have its own set of dependencies. This is something that many developers don’t pay enough attention to. What are those dependencies? Are those still maintainable and trustworthy? Of course, it will hard to check every dependency but a library with too many dependencies can be a warning sign.
It is always better to choose the one with the least dependencies.

Maintaining third-party dependencies

1. Whether you use one or more libraries, I recommend keeping track of them all in one place, along with a brief description of what they are used for. This is especially beneficial for more complicated libraries that developers may want to use in a different way. You can try to enforce consistency in usage on the same project and other projects this manner.
2. Once you’ve added the library to your project, make sure it’s up to date on a regular basis. Keep it updated if feasible; otherwise, if it is no longer maintained, consider replacing it with a new one by completing all of the processes outlined above. You will have less troubles in the future if you do it sooner.
3. Make sure that your product is safe from potential security vulnerabilities which are reported in third-party dependencies. Lack of visibility into the project’s dependencies and transitive dependencies has made it more difficult to take quick actions to provide patches. Always try to have a full picture of the dependency chain of your product and implementation level details. Then you won’t get many issues when mitigating dependency vulnerability risk.
4. Monitoring the third-party dependency task becomes a burden for developers. You can use a dependency-track which is an intelligent Software Supply Chain Component Analysis platform that allows organizations to identify and reduce risk from the use of third-party and open source components.
5. It’s worth considering what would happen if we were compelled to quit using a third-party solution for any reason. It’s a good idea to have a backup plan — a migration strategy that lists all possible solutions to your problem.

Somebody seems to have the solution to your problem, so why not use it? This will save you time. You should not only see the advantages but also the risk it adds to your product. To minimize the risk and to keep the stability of your product, you must go through a set of analysis before adding third-party libraries to the product. Detailed planning and analysis of your project, requirements, resources, time and risk analysis are the key factors in helping you decide which approach to take.

I hope this article helps you to some extent to understand the process that a developer should go through before integrating a third-party dependency into a product. Feel free to add your thoughts. Thank you.

References

1. https://www.thedroidsonroids.com/blog/third-party-software-pros-and-cons#When_to_replace_third-party_solutions_in_your_project
2. https://blog.undabot.com/third-party-libraries-yes-or-no-and-how-to-decide-22d4fd2d07a6
3. https://www.scalablepath.com/back-end/third-party-libraries
4. https://javarome.medium.com/design-third-party-dependencies-e4bcb0d816da