You can't rely on 3rd party software. Everything will be fine for a while and
then you'll get screwed and there's no way out. If you have the source that
is better, but there is still a large risk.

''That's assuming that you can do the job better than the 3rd party.  Think about the sheer amount of 3rd party software you are building your apps on top of.  If you're building (say) an e-commerce web site, you need a database server, a web app server, a compiler, an operating system...  If you're an app company, can you write a better OS than Linux?  And if you can, do you want to spend the man-years doing so, or would you rather be first to market while there actually is a market?  Any OS, compiler, or DB server I write will be a lot riskier than what's available for free.''

----

I suggest a company try to buy the source code, and then customize if possible rather than buy executables. It is easier to customize to fit local needs that way. Also, look at the data schemas of any large package that you may buy. If the schema does not fit your business well, toss it! If they don't let you access the data for your own needs, toss it!

----
This gets really fun when working on "certifiable" software, where you have to prove that every line of code is executed (no dead code), every decision path is taken, etc.  Imagine having of strip down a 3rd party standard C library to only the parts that get used.  The worst was a stripdown of sprintf to handle simple number formatting.  For all that effort, "build don't buy" might have been far faster and better.

Admittedly, certifiable software is somewhat of a special case, given the relatively small number of developers in this position.
----
Contrast with BuyDontBuild