[alexjeffrey]

I think your example also speaks to the argument I put forward to some extent - SpaceX initially chose to use a 3rd party turbopump as building an efficient turbopump isn't their objective. However, at a later stage when the 3rd party turbopumps became an issue (whether that be because they were faulty, not efficient enough or any number of reasons) SpaceX decided to build their own.

This seems like the correct way round to me for the majority of cases where subcomponents of your product could be externalised - a 3rd party should be the primary go-to choice unless a company cannot be found that fits the requirements. The issue I see in development (and have been guilty of in the past) is simply building everything when libraries could easily cover the use case - "not invented here" syndrome. That's the real problem.

[edit] Also I think it's clear that there'll always be cases where the default doesn't apply, for example when working with a new field/concept or where the 3rd party options are too far from the mark, but for the majority of development (especially web development) there's likely a library/service to match many of your requirements.

[chacham15]

What you are missing is that every library has its own dependencies and set of libraries. Gitlab uses nginx, unicorn, mysql, and a few other technologies. Ganglia uses apache, python, perl, and a few others. If you continue to add components you end up with seven different web servers, application servers, and little spare system resources and we havent even started talking about how to get these components to play nicely together! In conclusion, yes, it is nice if you can simply outsource to a library, but many times you have to bend over backwards to do so and it simply isnt worth it.

[InclinedPlane]

It depends a lot on scale. If you're just throwing together a web app that isn't going to have crazy amounts of traffic or business then maybe a big messy dependency chain is ok. But every one of those dependencies is a risk and a liability, and the more valuable and significant your project becomes the more important it is to lock down risk and reduce liabilities. Which means tracking down and eliminating dependencies.

[InclinedPlane]

One of the things at play here is the Dunning-Kruger effect. It's pretty common for there to be lots of different libraries and little tools and whatnot which duplicate existing tools but do so poorly. And part of the reason why is that it's often easy for people to look at those other tools, see the faults in them and think to themselves that they could do so much better with very little effort. But often this is wrong due to an inflated sense of ones own capabilities.