You know what I mean ... every IT professional has been faced with this dilemma, and you have probably known radicals on either side of the argument.  I admit that I myself have swayed pretty wildly on this issue in the past, but after some serious thought and research I think I have boiled this debate down to its crucial elements.  I will refrain from the overused (but often true) adage of "it depends."  One article I found written by Bruce Lewis presents a good overview of the argument.  It was the primary basis of the drawback sections below, but I trimmed it down some and added parts I thought were missing.

Drawbacks of the Buy option

Companies pursue the buy option because it will be easier and faster than building custom software. Nevertheless, buying the right software is a project in itself.

• Evaluation: When buying software, it is often difficult to determine which packages you want to look at seriously. Marketing literature is often vague and unhelpful. If you're lucky, you can download an evaluation copy either by paying a nominal sum, or by providing personal information so that their marketing people can contact you. If you're unlucky, you'll have to negotiate with them to obtain an evaluation copy.
• License Hassles: Once you've settled on a particular product and installed it, the particulars of the licensing agreement begin to bite you. If you use a license server, will you be unable to use the software when that server is down? The last thing a serious operation needs is another point of failure. If you're licensing server-side software, do you need another license for a hot spare? What if you want to do testing on a separate server? What happens if the license is tied to some kind of hardware ID and a disaster forces you to restore from backup onto different hardware? A site license might be helpful, but what if you have users who may want to run licensed client software from home through their own ISP? Does the site license cover that case?
• Lack of Customizability: At best, buying off-the-shelf software gives you most of the functionality you want at relatively low cost, but there's always some functionality you wanted that isn't there. Often there are simple changes that could make the software much more suitable for your task. Measured over the lifetime of the software, such changes might save the users a lot of time (a.k.a. money), but you have no way of making those changes.
• Obsolescence: Ever been stuck with a piece of software you can't legally run anymore? Ever sink money into "the standard" only to have its support discontinued a few months later? People who buy software because they think it will protect them from obsolescence often get a rude surprise.  This happens because bought software, if it stops generating enough revenue to support marketing, legal and other departments necessary to run a software company, dies completely. It's unlikely that another company will pick it up.
• Urgent Bugs: Even the best-laid business plans can be waylaid by software bugs. What happens then? No amount of money can force a large software company to put your bug at the top of their list, no matter how urgent it is for you.
• Integration: It is often difficult to integrate off-the-shelf software with other business applications, and it is sometimes even necessary to create an additional software layer to help the two communicate.  And even if you can get it working with the rest of your stuff, several different pieces of software that have been patched together are typically complex and less stable.

Drawbacks of the Build option
To a developer, this almost always seems like the obvious choice ... because you design every detail, in the end you have exactly what you wanted (hopefully).  But this shouldn't be "the default" decision either, because there are significant cons we sometimes conveniently forget about.

• Lack of Maintainability: The biggest nightmare of software built in-house or by a contractor is that the author will leave, and nobody else will know how the code works, how to recompile it, or sometimes even where the code is. This situation means job security for the author, but insecurity for the organization.  Beyond that, after software has been built there is a “hidden” cost of the ongoing maintenance and support required that most people forget to weigh in the decision.
• Lack of Standardization: There's a training cost associated with software you build yourself. New employees need to be brought up to speed on your system, even if they've used software elsewhere that performs similar functions. This is one of the most common reasons why people choose to buy software even if it doesn't completely fit their needs.
• Obsolescence: You usually choose to build your own software when nothing else is available to fit your needs. But what happens if off-the-shelf or free software later becomes available that would fit those needs and do even more? You find yourself supporting an obsolete product.
• Urgent Bugs: Build-it-yourself software does have an advantage over bought software in that you can fix urgent bugs yourself. The down side is that you have to drop all the other important things you're doing to fix the bug, and usually only one person knows the code well enough to fix it.

What It All Boils Down To

“Buy rather than build where differentiation isn’t critical” - Joe Morgan

That is a quote that really sparked me to write this article.  I ran across it in the September 17, 2007 edition of Information Week, in their “CIO Values” column, which highlights a different CIO in every edition.  This is part of what Joe claimed as his guiding principles (the other part was to create services for reusable business components … also important).

I love that quote because it is so clear-cut and simple, but let me try to put some more flesh on the concept I am trying to drive home.  If the functionality you need is something that is unique to your business, core to your company’s strategies, and provides a significant competitive edge over competitors … then even a slight difference between the ideal software you could build and an off-the-shelf product is critical and might be enough to justify building a custom solution.  However, if the functionality you are trying to attain isn’t something unique to your business, and there is a product out there that may not be completely ideal, but includes most of the elements you are looking for … then “differentiation isn’t critical” and you should buy it.

I think of Joe’s quote almost every time I find myself questioning whether we should buy a particular software package, software components, or tools.  Of course we could probably build anything if we wanted to dedicate the time to it … but is that always the best long-term choice for the company?  Probably not.  There has to be a balance there.  Buy software when you can, and build it when you must.  Ask yourself "Is this something unique to my business, and is the differentiation critical?"