Nobody is 'gatekeeping' anything. Words have meanings, and have existed for a long time. Their meaning is well understood at exec, management and engineering levels and don't need to be redefined. You seem to assume that I'm writing about technology lock-in, which I am not. I am writing about the ability to use a different vendor. Not about runtime cost or integration.
Known runtime cost is part of normal OPEX. Having to reverse engineer something because your MRI vendor won't give you the specs to write drivers for the 64-bit PCI-X acquisition card is vendor lock-in. If you need more examples, just ask around in any organisation of reasonable size. And no, we are not talking about individual people here (just in case you were making that assumption - it's hard for me to detect that in your writings).
If you want to change the meaning of what vendor lock-in means (it already has a definition, which I have written down a few times for your ease of not having to look it up yourself), good luck trying that out in your own context.
Just for the sake of completeness, here is a random paper that explains it in extra detail: https://personal.utdallas.edu/~liebowit/paths.html you could have found that relatively easily, even Wikipedia refers to it making it highly discoverable. If you don't like papers that are published by the author, feel free to request a copy at the Journal of Law, Economics, and Organization. If an explanation, reference or paper isn't good enough for you, why bother posting at all?
Perhaps the simplest distinction might be: you keep talking about OPEX while vendor lock-in is vendor-controlled CAPEX to 'get out'.
Okay, that's fine, but it's still vendor lock-in. I don't know why it's so hard to understand. If you buy a product and use it and then you can't get out or switch or use the product with some other hardware or whatever, it's vendor lock-in. You are locked into that vendor. If you buy a Mac and put a bunch of files on it that only work on a Mac and your Mac crashes, you can't restore the backups to a windows machine or an ATOM processor machine.
Thus, you're locked in. Thus, vendor lock-in. It's pretty cut and dry really.
Vendor lock in is an attribute, or effect, which is not the same as “another term”. You can’t start an argument about semantics only to bend this language so drastically.
Vendor lock-in is just the price of using a vendor, and one which is often overwhelmingly worth paying. What you are saying is true, but it's not really enough of a detraction to justify building everything in-house.
Got it - thought you were saying vendor lock-in meant the standards were de facto not open (which seemed unfair, the standards are transparent and not unusually difficult to implement).
I think that's a very rigid definition of "lock-in" that implies it must be done with some anti-competitive malice. That's not how I've encountered the term in my past, so I'm welcome to other interpretations.
Per (not authoritative, obviously) wiki:
"In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."
I agree with this. It shouldn't require that the service is purposefully preventing you from changing; lock-in can occur because a service offers advantages that prevent changing by virtue of some other cost.
Thanks, that's interesting, I didn't know that. On the one hand, I shouldn't be surprised since vendor lock-in is the standard way tech companies try to gain corporate advantage. On the other hand, it's kind of depressing to learn once again that customers count very little and no matter what these companies say, they will always try to abuse us in every way the law allows.
I think past vendor lock in wasn't so much about the technologies involved, but the inability of organizations to transform. If you have the right approach to application development/deployment/management there isn't a way any vendor can lock you in for any significant amount of time. I see more people wasting resources developing to avoid lock in when the applications they are developing won't live long enough to ever worry about having to move off of the systems they are developed on.
I'm not saying we should never be concerned about vendor lock in, but I think the concerns need to be balanced against the costs (and complexity!) of engineering everything to be immune from "vendor lock in".
If they provide a compelling product offering, and the people understand what's available where, and choose to use it, then I guess that can be called vendor lock-in. But it's hardly nefarious.
When the vendor lets you export your data in a form that you can easily import into your own copy of the exact same software, I fail to see how that is "lock-in". If the vendor increase the cost of the service or changes other terms in a way that's unfavorable to you, you can easily leave, that's the opposite of lock-in.
You can't really accuse a vendor of lock in just because his product is priced lower than it would cost you to do it yourself.
Is there a name for what happens when a vendor gets locked into the technology of its users? E.g. Microsoft basically getting stuck supporting ancient DOS software until the end of time.
This crazy compatibility and lock-in is Microsoft's biggest advantage, but it's simultaneously a huge weakness.
No, you seem to be confusing "vendor lock-in" with "monopoly". The above isn't what is meant by "vendor lock-in". Here's a good explanation by Cloudflare:
> Vendor lock-in refers to a situation where the cost of switching to a different vendor is so high that the customer is essentially stuck with the original vendor. Because of financial pressures, an insufficient workforce, or the need to avoid interruptions to business operations, the customer is "locked in" to what may be an inferior product or service.
A practical example of vendor lock-in is an elderly aunt with mine who has an email address from her ISP. She isn't "contractually obligated" to continue using that email, nor the ISP. The ISP certainly doesn't have a monopoly on email. But the effort to switch from an email that she's been using for 15 years is very high for someone with weak tech skills. I'm probably in a similar situation with Gmail, as it's the primary contact by which most people know me. I can't take my Gmail address and port it; I have to create a new email and get people to update their address books.
Known runtime cost is part of normal OPEX. Having to reverse engineer something because your MRI vendor won't give you the specs to write drivers for the 64-bit PCI-X acquisition card is vendor lock-in. If you need more examples, just ask around in any organisation of reasonable size. And no, we are not talking about individual people here (just in case you were making that assumption - it's hard for me to detect that in your writings).
If you want to change the meaning of what vendor lock-in means (it already has a definition, which I have written down a few times for your ease of not having to look it up yourself), good luck trying that out in your own context.
Just for the sake of completeness, here is a random paper that explains it in extra detail: https://personal.utdallas.edu/~liebowit/paths.html you could have found that relatively easily, even Wikipedia refers to it making it highly discoverable. If you don't like papers that are published by the author, feel free to request a copy at the Journal of Law, Economics, and Organization. If an explanation, reference or paper isn't good enough for you, why bother posting at all?
Perhaps the simplest distinction might be: you keep talking about OPEX while vendor lock-in is vendor-controlled CAPEX to 'get out'.
reply