Tim Barcz blogged about attending a session at the recent ALT.NET conference that centered around why people choose a first gen Microsoft product (but you can apply this to any vendor really) over a more mature open source project.  You can read Tim's thoughts here.  Tim gives a good example of one of the big benefits of open source and that is being able to fix the source when you encounter an issue, but I'm not sure it really tackles the original question though - "why some (many) developers, managers, and executives feel comfortable choosing a brand-new Microsoft product when a far more mature open source alternative exists?"

Tim demonstrated one great aspect of having open source - being able to fix bugs on your own or modify the code to suit your particular application or scenario.  But the reason Tim talks about for not wanting to go open source in the first place (lack of known viability and a desire to NOT have to support that code base) still exists.  Yes, you were able to fix an issue, but you are still responsible for maintaining and versioning that code from now on.  Now, if you submit the bug fix back to the project and it gets rolled into the code base, life is good. 

Yes, having the source is nice in the scenario Tim paints - fixing bugs, extending, whatever.  But it does not alleviate the original problem of "I don't want to support that code."  Now for larger open source projects, that is probably not a valid reason to not choose open source since they have become so large and popular that they have a high probability of being around for a long time.  For small to medium projects, however, the long term viability may be a bit more dicey.  If I have a "big vendor" solution where I have a higher degree of confidence that it will be around for a while (yes, vendor solutions sometimes "disappear" as well), then I have mitigated the support risk out of the equation.  Yes, I give up a lot in exchange for that, but it is a trade off that makes business sense in a lot of cases.

Now some will say, "but if vendor A discontinues that project" or "if Vendor B goes belly up" you are much worse off because you don't have the source.  I don't agree because what I am really faced with is a migration effort to another supported platform or taking on support of someone else's code.  If my desire is to mitigate the amount of code I have to support, having a particular closed source solution basically needs I would need to migrate as opposed to take on a software support activity.  That is a valid goal for organizations where software development is not their core competency. (because I have the source does not mean I have the time, resources and/or technical expertise to support it or even take advantage of it). I shudder at having to think of having a large code base that I am now responsible for making sure runs on the next version of x dev platform or y operating system.  I think this stems from a lot of open source advocates of not realizing that if your business is making widgets, your really don't want to get in the habit of directly supporting any more code than you absolutely have to.  If I have limited on staff dev resources, I can see a lot of scenarios where I would rather bite the bullet and migrate than take on support.

Another way to look at it is the exploding interest in SaaS applications.  Companies today do not want to even support applications on premise if they can avoid it.  They would much rather let someone else support certain applications since it is cheaper and a better utilization of the company's core competency assets.  But for some reason being able to bring large amounts of source into my organization with the idea that I may some day have to support it and say that that is always a good thing doesn't make a lot of sense.  That is a very broad brush to use and by no means am  I saying that open source is bad, shouldn't be used, etc.  There are a ton of great open source solutions out there, but there are a ton of good reasons to go with vendor solutions (even less capable ones) if you look at things through a different lens.  I don't think its a slam dunk either way and both sides can be right depending on the solution, the vendor, and the company.