How to choose third-party software

We have learned, sometimes the hard way, that reinventing the wheel is mostly not a great idea. For many tasks or problems you face when writing research software, someone may have written a library for you to solve it. Why would you code up your own database? Why worry about finite element assembly? Do you really need to have your own logging solution?

It is tempting to just go out there and take one of these libraries which do the job for you. In many cases, this is not only a tempting, but also a very good idea. Using external libraries will help you to focus on what you actually want to achieve. If you pick the right tool, it will do the job way better/faster/more secure/more elegant/more usable than anything you can come up in your own, valuable coding time. Using a mature, well-maintained, weatherbeaten software to advance your own research makes you stand on the shoulders of giants.

However, there are drawbacks. Relying on a third-party software (a library, a tool, code snippets, or similar) introduces dependencies. Installing, porting, updating, and potentially using your code may get harder. Licenses need to be considered and sometimes these licenses will impose restrictions on your own code and its usage. What will happen if the external dependency is not maintained anymore or will be removed from the repository you used? Or worse, it gets compromised by malicious code, leaving also your code and the systems you use vulnerable? And yes, in parts this even contradicts the list of benefits listed above.

So, how DO you choose third-party software, if at all? This is not easy to answer, but there is a general rule of thumb: If the software you found is following good software engineering practices, it is worth investigating further. In a way, this is the inverse Golden Rule of using other people’s software: you know what you should do when writing software, so look for these things when selecting a dependency.

This does not mean the selection process ends here. You still need to think about license compatability, dependency hell, portability, security, and potentially more. In any case, consider writing your own code in a modular way so that the dependency can be exchanged more easily. And finally: if your software only uses that single functionality of the monstrous code you found somewhere on the internet, you may consider implementing it yourself after all.

Further good readings about this topic:

• Choosing a Third-Party Library, at medium.com
• The Open Source Way 2.0
• Dependency Hell, at wikipedia.org

Let us know what you think and get in touch! You could come along to our Open Hours each Wednesday either in person or online to discuss this further or bring it up on the internal rocket chat channel 'RSE' to have a conversation that involves more of the community.

Author: Robert Speck