I could argue that Open Source as a concept was created largely due to the distrust that surrounds Microsoft and UNIX vendors. Given that it was UNIX that was most hard hit by Linux, it is hard to argue that if folks were satisfied with where they were they wouldnt have changed. And the UNIX vendors as a group didnt cooperate with each other soon enough nor did they respond to the move to x86 hardware fast enough to protect their own base, and a long list of empty promises just made things worse.
Are You (And Your Apps) Ready For Vista?
SOA Software Pushes Workbench Governance
Get a Life: Enterprises Eye Potential For Second Life
IBM Signs on For Small Business|
Microsoft should have been the beneficiary of this problem but trust actually appeared weaker with Microsoft, and the Linux wave was fueled and grew to near tidal proportions. At the core of this wave is a sense of distrust that forms the need to actually look at source code because vendors are not trusted to do what they say they are doing. This is true even though few IT departments have the time or the skill-set to analyze complex products to the level of detail required for a true operating system review (most seem to think someone else must have done it).
The fact that these proponents often seem to trust strangers more than they trust vendors is telling. And it creates, at best, an uneven trust standard when it comes to Linux and Open Source. Both Novell and Red Hat, as smaller service-oriented companies, tend to do more to engender trust but I often wonder if they truly understand its importance.
The reason trust is important is that when you trust someone you are confident they have your best interest at heart. The reason it is important to assure trust is to, on one hand, make sure they dont take advantage of you (blind trust is stupid) and also, to make sure you dont waste substantial time and effort making sure a vendor is, in fact, behaving in a trustworthy fashion.
My overall sense is that you have two choices when faced with a loss of trust with a critical vendor. You can attempt to fix the relationship through escalation and staffing changes, or you can extract the product and switch to another vendor. However, if the problem was largely or partially related to how you handled the relationship the experience with the new vendor may turn out to be worse. In fact it often is, in my experience, suggesting the first path should come first, and only if you are sure you cant repair the relationship should the second be taken.
This is as true with Novell as it is with Microsoft, with Oracle as it is with IBM, and with both Sun and HP. Saving a relationship with a vendor is virtually always vastly cheaper and less painful than extracting that vendor because the dependencies are almost never known.
One of my first IT experiences as I transitioned between Finance and IT was the removal of a national payroll vendor who wasnt meeting our expectations. We got a call after the new contract was begun from our CEO, who informed us that the vendor we had just moved from was also our largest national customer. A lot of career blood was spilt on that deal and we didnt even see it coming (there were a lot of Finance and IT executives that signed off on the change). We ended up retaining the problem vendor and working harder on the relationship, and the result was actually better than anyone expected.
So my advice is, if you have a vendor you dont trust, try to analyze and fix the relationship first. If you cant, then find a way to replace them because it makes no sense to retain someone in any capacity you dont trust. Oh, and you may want to watch the vendor gifts. I saw a number of folks get new careers because they accepted things they shouldnt have over the last 5 or 6 years and auditors are looking.