All programmers face a problem when writing any new code. How much code should come from first principals and how many libraries to use? New programmers prefer libraries. If the library is well written then it works fine. Unfortunately libraries are rarely well written. Libraries may contain security flaws or bugs just like any program. How do you know if a library is well written?
Code can be open or closed source. While open source software has source code available for anyone to view, in reality people never look through the source code. So while open source has the ability to be more secure, it rarely is. Open source also means malicious actors can access the source and look for exploitable bugs. Open or close source isn’t an indicator of how good a library is. Generally, good programmers write good libraries and there aren’t enough of those. Keep in mind that some open source libraries have licenses that limit where they can be used.
Security can be a huge issue. For projects where security is paramount, every library must be reviewed. This typically means running a set of automated tests for the library functions you use. Writing automated tests can be time consuming. If a library fails some of these tests then a new library may be required. New libraries mean a new set of automated tests because each library does things differently. This process is hard to predict, which makes it a large factor in project estimate unknowns. Security issues may or may not be bugs, which leads to the fun topic of library bugs.
Library bugs have their own set of issues. Since every library does things differently, changing a library after it’s integrated could require a redesign. These changes could be significant. For example, one library is based around blocking sockets and single threads but half-way into development bugs are found that can’t be worked around. Suppose the only other available library uses non-blocking sockets and in and out queues. This could lead to a significant rewrite of existing code before it works efficiently.
One common problem in open source is that common features work while uncommon features can often fail. This happens due to their QA process, or lack thereof. The typical QA process of open source is to rely on third parties to report any bugs and then fix them. Commonly used features will end up working while uncommon ones may have never been tested. Closed source may be better in this regard, or it may have the same issue.
If an open source library is used, programmers have the option of fixing this library. They would have to first learn the code and that may be lengthy. If they make a change and upload it to the open source project, that change may be rejected for legitimate reasons. Then future releases of the library may cause bugs in your software. This brings up the topic of updates.
Projects must also remain up to date, which means libraries will be updated. However every time a library is updated it could introduce new security issues or bugs. So every update may require a new security audit and bug check. If the library changes how they do things, which often happens with open source, it could require significant changes to the program that uses it.
The choice between finding a library and writing your own is often difficult. Finding a library could save time but it could also cost more time than it saves. There are no clean rules to follow, one can only learn from experience.