[lmeyerov]

I was following it up until the vendor FUD. For most of the code your part of the orgs wants to run, chances are, you aren't hiring the world's best dev/prod/designers to dedicate their lives to say your website's anti-spam comment forms -- they're going on the differentiating stuff! For the boring whizbuzz widget, the top vendors in the field will already have centuries/millennia worth of worker hours & experience behind it. And, even if you picked a wrong vendor, should be waaay less political to replace them.

One phrase that I've increasingly come to love is "torpedo in the hull" (https://allaboutstevejobs.com/blog/category/steve-jobs-histo...). It's tough seeing senior folks tolerate vendor-outsourcable projects going to weird internal special projects & artisinaly-managed OSS. We know most folks switch jobs every couple of years now, including those behind that fancy internal project, and inheriting unnecessary code & ops is such a drain. Why encourage planting timebombs?

[TeMPOraL]

There are trade-offs to everything, and a lot depends on a deal you have with your vendors. But if anything, it's the vendors that are the actual "torpedo in the hull" - a foreign body in your system, that you have very little control over and that can explode at any moment, leaving you with a vendor-shaped hole in your company. It's manageable when the third party is a commodity vendor - you can replace your printing house or blog host every other week at almost no noticeable difference. But in the world of software services, everyone is doing their damnest to not be a commodity, to make themselves unique. That uniqueness means a larger hole when they go down (or get acquihired), and also stronger ability to extract money from you. A codebase you own won't one day tell you that, starting next year, they're discontinuing the service package that was critical to your business, and now you have to buy two separate service packages plus a custom integration fee just to retain the functionality you grew dependent on.

[lmeyerov]

Right -- this is about commodity stuff. Agreed, asking a vendor to own your non-commodity bits means not owning your core speciality, which adds even higher levels of risks.

A nice thing about vendor-shaped holes in commodity areas is the holes are clear and plenty of vendors happy to quickly fill in. Comparing that to changing some internal project that gets its tendrils into who knows where with who knows what servers & services is night & day. I much rather figure out a Hubspot-to-Wordpress-and-Marketo migration or Zenefits-to-Gusto migration than some weird internal Elixir, Java, & InfluxDB Zeit blog spread over a bunch of AWS services that were primarily developed by two microservices devs who had both left the company to their next great thing over a year ago.