Just how would you feel about being able to browse and debug the client's source code when you get this red box with black text? As for support: it sometimes doesn't take more than a few hours to get a response to a problem for most popular free code, whereas I once discussed with a Microsoft support representative over email for weeks without being able to get a solution to a problem. This is why the Notes forums are a much better support alternative to me than regular customer support.

Corporate mission-critical applications should run on the server. I'm talking about the client part here. Additionally, there was a test I saw a few months ago testing the compliance with standards of several C++ development environments. One of the tested competitors was gcc + glib. Guess what: they scored among the best from, I think, 14 competitors, way ahead of Microsoft development tools. This means that, when using commercial C++ development environments, you're in most cases worse off and need more paid support than the free support you get if using the free solution. Additionally, everybody knows that except for compilation speed, gcc is a strong competitor for most commercial compilers, and there isn't even one competing commercial product when it comes to cross-platform compilation and portability.

If you're using the same internally developed library in the server in client parts of an also internally developed application, do you really think it's efficient to maintain two slightly different source trees just to be able to compile your library on the Windows client and on the non-Windows server?

Mick takes the floor again
I can't dispute any of that, but I'm still leery of including free code in mission critical applications. I'm not against free code, far from it. For example, check out my DominoPower piece about LotusScript class libraries on the Notes.Net sandbox at http://www.dominopower.com/issues/issue200110/script001.html.

I accept all the arguments about free code being a labor of love rather than a commercial offering and the fact that such things are often of better quality because of it, Linux itself being such an example. I can even see the argument that if there are problems, you can get in there and debug it yourself. But I'm not convinced that such things should be used without great forethought and care.

Paid for software comes with a moral and ethical warranty, even if not a real one, that it is fit for the purpose it's sold for, and if not, there's a moral obligation that the vendor should fix it. If you use free software, the supplier is under no such obligation. I will accept that many of them take problems more seriously than many software vendors do, but what if the author is on vacation in the Galapagos Islands for a month?

As to debugging it yourself, yes, it's always an option, but if you have to do it, your back is already against the wall, even more so if the developer is in the Galapagos and his mobile phone battery is flat. I'm not sure that your shareholders would always see the arguments in exactly the same light that you do.