1. I realize the source is available, but I want my developers

developing OUR software not OS (Fill in your other FOSS software here) software.

Not relevant. The developers may alter open source code, but they may not alter the code received from the proprietary vendor, in most cases. Assuming your developers will develop the same breed of software in FOSS land as they would in proprietary systems, this statement has no bearing on the discussion whatsoever. More importantly, in the open source community there are more freely licensed libraries than are available in from proprietary vendors, and the same code and libraries are available for Windows as well.

Competent developers that stick with LGPL licensed libraries and with more basic tools such as those commonly available for PHP and perl will have no issues whatsoever, given the most basic level of awareness of how to work with these licenses.

The statement above seems to imply more a fear that your developers are incompetent and will plagiarize code incompatible with your company's desired license than it does anything else. Again, the same code is available for Windows as well, and would be equally applicable if you were working with something like Windows CE. This point is not all that terribly strong.

2. If I buy a piece of software that is closed-source, the company selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.

This point is, but there's a major trade-off. You must choose between being locked in and supported by the author company or having free choice of several large firms that are each similarly well suited to remedy your problem. The major commercial distributions support developers that at the very least package and closely monitor and, at the other end of the spectrum, actively develop all the major packages in the operating system. If something goes wrong that can't be fixed without a software change, this means you're actually far more likely to be able to find the fix in the FOSS environment, due to third parties having greater access to the code and greater familiarity with the code.

An argument can be made ( http://msuspartnerblogs.com/blogs/nealw/archive/2007/03/25/7708.aspx ) that Microsoft patches their code more quickly than Red Hat, Microsoft routinely has far more severe security holes to patch. Equally important, if you are aware of a bug that is affecting YOUR systems, it is far simpler to use your clout with an open source vendor to get the problem fixed than trying to steer the monopolist, for all the same reasons one could not hope to move Ma Bell, and one can only rarely hope to push Apple because they are run by space aliens. In the open source community, the numbers of third parties that are capable of fixing an application, library, etc that is broken in a way that effects you makes it far simpler and, if needed, far quicker than dealing with a closed source vendor.

Furthermore, when dealing with applications, Microsoft might sell SQL and HTTP servers, but they aren't going to sell you your entire application stack, unless you're in a mind bogglingly boring company. A Linux distribution is, and will support it in its entirety.

3. If I buy [closed-source company]'s software I know it will work with their Database, Mail server, Office Suite, etc. because it is made by the same company. I'm not sure that we'll be able to get [open-source company]'s software to talk to our existing infrastructure, our to our partner's existing infrastructure.

As stated above, yeah - Microsoft's Office is going to integrate with Exchange effectively, for the most part, and it is far more stable and mature than it was. Previous builds that I've seen were enough to drive me nuts, and I'm still far more comfortable and capable dealing with a Maildir mail store than their proprietary ones, but I can see the benefits.

But again, those three applications and the OS are not all you're buying. Red Hat, SuSE, Ubuntu et al will actively support most every application and library that they ship. While they are the initial authors of little, they, again, are the authors of parts of most of the applications that they ship. They offer support for a broad, overarching range of applications and libraries that makes Microsoft pale in comparison, and, if you're displeased with their take on an issue, you can take your specific issue to another company with far greater ease.

On the infrastructure point, however, you're making a permanent choice if you're going with a vendor that's going to lock you in to unpublished proprietary protocols to do something as mundane as mail transfer. Only one part of MS Office integrates in any meaningful way with Exchange - Outlook. Unfortunately, their ancient webmail application bundled with Exchange is still a crufty POS, and I'm not referring to points of sale. In Linux, you have many, many other options, but, if you want a full groupware suite, there only appear to be three or four that matter, counting the proprietary, cross-platform Lotus Notes. Each ships with a mail client just as tightly integrated with their server solution as Outlook and at least one shares developers and tight integration with Evolution.

More importantly, the vast majority of these systems use open standards to perform the shared calendar tasks, to push and store their emails, etc. This means that you have far more choice.... or rather, you have SOME choice, unlike with the Microsoft groupware server, which is solely designed to work with Outlook. While Outlook may be slightly more refined than the others - I wouldn't know, I just use Thunderbird, and am aware that its scheduling system is still very much under development - it is just as important that that same choice also gives you many, many options for a webmail system that doesn't suck. Fancy AJAX mail clients that perform on par with Gmail are available for free or a pittance, and other mature mail systems that are far more user friendly. Full PHP groupware suites such as the Horde also exist, although I would not recommend them at present - seen our install compromised one two many times. More mature and stable mail systems such as iloha and Squirrelmail also exist, and suck much less than the one shipped with Exchange.

The question you have to ask yourself, on a case by case basis, is does X proprietary vendor offer features L, M, & N that are so beneficial that they outweigh the benefits of: A: Having multiple available vendors that are able to support and, if need be, develop the application. B: Having vendors that are willing to support and, if need be, develop the application. (Ever tried to file a bug report with Microsoft? It isn't pretty - http://www.oreillynet.com/mac/blog/2002/06/mission_impossible_submitting.htm... ) C: Using published, open standards that will allow us to integrate products from other vendors and projects in the future, and allow us to develop our own related applications and systems in the future. D: Your personal experience and comfort levels with UNIX, which just happens to be FOSS. Retraining in the latest and greatest proprietary application costs an arm and a leg. It had better be worth it, if the boss is going to have to put you through that level of rigorous training or willing to pay the expense of training an already expensive new hire already familiar with that fledgling technology to work within your firm.

-Sean