Every third party tool (or library dependency, by the way) is something that will have to be well understood, maintained and fixed when broken. Which is why I try to avoid them for the most part in my personal and work projects.
When someone at work says "Hey, lets just use Xyz package I found online! It does just what we want!" you need to ask: Who fixes it when it causes a problem that stops us from shipping? Who does the security audit? What data does it collect, and to where does it send that data? What will adding it do to our software's performance? Who decides when to update it to the next version and verifies compatibility? Is its license compatible with our workflow/software?
All of a sudden, people are less excited about that great doodad they found on StackOverflow! I'm always troubled by the cavalier attitude about relying on external tools and library dependencies. Yolo just pull it in! In some cases it might be the right decision, but not always. And, avoiding third party stuff is not always just blind NIH mentality: There are costs to depending on someone else for your project.
I strongly agree that bringing in new dependencies is not a small consideration. But at the same time, third-party dependencies will always be necessary and by carefully choosing those that are best suited for the job, you might be able to get a net reduction in complexity.
Old, established third-party dependencies are not necessarily better for the job than new, trendy dependencies. Their entrenched nature can be an advantage and also a limitation. And when you roll it yourself, then that is of course the newest and least established solution of all.
If you rolled your own, you invest your time to learn about the problem domain. If you use third party libs, you invest your time to learn about its interface/behavior. That is usually much more ephemeral knowledge. It is good tradeoff if the library does some heavy lifting, but that is not always true.
When someone at work says "Hey, lets just use Xyz package I found online! It does just what we want!" you need to ask: Who fixes it when it causes a problem that stops us from shipping? Who does the security audit? What data does it collect, and to where does it send that data? What will adding it do to our software's performance? Who decides when to update it to the next version and verifies compatibility? Is its license compatible with our workflow/software?
All of a sudden, people are less excited about that great doodad they found on StackOverflow! I'm always troubled by the cavalier attitude about relying on external tools and library dependencies. Yolo just pull it in! In some cases it might be the right decision, but not always. And, avoiding third party stuff is not always just blind NIH mentality: There are costs to depending on someone else for your project.