Big risk
-
When you are developing a long lasting product, using third party components has several risks: - you can face a bug all of a sudden and get in deep trouble - usually at the worst moment - because there is no maintainer available (the company went out of business, the freeware project died or you can't afford the cost); - trying to fix a bug yourself from open sources can be a nightmarish endeavour; libraries can be huge and written by gurus in the least readable way; architecture documents are often unavailable; all you can do looks like quick and dirty hacks; - adding a feature of your own when required is an assault course as well; - packages are often overfeatured for your needs; you'll have to carry a monster (redistribute it and complexify your installers) for the rest of your life; - big packages are sometimes so complex that the effort it takes to master the API and comply with it may not be worth; - last but not least, portability is the main thing; my code needs to be compatible with all MS compilers from VC6 to VC2012, as well as gcc, and future compilers; if a third party library fails to support one of these - which is quite likely to arise -, I can get in big trouble; and this is unpredictable and out of my control. When dealing with your core business, integrating black boxes is not so reasonable.