Is Vendor Lock-In Really a Bad Thing?
devcentral.f5.com
devcentral.f5.com
The author tries to link the fact that people would like to see data portability in cloud computing to the success of consumer stuff like the iphone and the like.
They are completely different beasts and you can't compare them like that.
As for the closing question: "Has the possibility of “vendor lock-in” ever stopped you from making a purchasing decision or is it just a “potential risk” that’s weighed in the overall decision making process?"
Yes, every time. And unless the product has very limited utility for me (say facebook or something like that) I refuse to put myself in to a position of 'lock-in' because experience has taught me that it is only a matter of time before the thumb screws come out.
So even 'free'+'lock-in' won't cut it for me.
There's also a difference between something that might be better in the short-term (say over 2-3 years) and something that is good for the long haul.
But I feel the same way as you do, mostly. I'm just more willing to make that trade off for say, a Kindle, knowing that in the near future I'm jumping to an open platform as quickly as possible.
The DX isn't available here though, so I guess even that will have to wait.
The reason your 'typical' consumer and the HN audience approach this in a different way is probably because a consumer usually isn't aware of the exact moment they are locked in, they only find out to their regret much later.
But by then it is too late, and the price to switch is too high.
Assuming that's even possible or realistic, which it often isn't in markets dominated by a single vendor. Supporting vendor lock-in, particularly as a developer, makes it harder for open alternatives to exist. It's common for a single vendor to dominate a market for years. The future of jumping to an open platform could simply never come to pass.
The cost of that? Well, one can sketch out part of the opportunity cost of that. Consider ITA which fuels Orbitz and others. Their technology, running our idea of modern servers, gets at least an order of magnitude better results than the mainframe technology it replaced.
This old iron doesn't even have files or filesystems.
When your application has to be up and has to service an entire department or organization for decades on end, the IBM mainframe platform is pretty much the only choice.
I've worked for a bank and have seen two serious mainframe crashes. They're rare, but they do happen, and when they happen you can bet that the vendor will get involved because it really isn't supposed to happen. Unlike the PC world, where if a machine crashes it gets rebooted and nobody bats an eye. I blame the 'we're not to blame' culture around PC software manufacturers.
You're spot on about the IO, that is the place where big iron really shines.
The place where I worked had both Sperry and IBM stuff (we got 'bought' and had to move all the software from the Sperry machines to the CICS environment on a 4381).
Sure your typical mainframe shop would prefer it if there was a competitive market, but for really serious OLTP, nothing touches a mainframe still.
Also, arguably, the "it's all a database" approach is superior to files and filesystems. It's what Be had and what Microsoft has been struggling with for 20 years.