6 ms·

> "making it hard to move your business data and processes to a different offering", not "network costs money" Correction: "Network costs obscene amounts of mo

> "making it hard to move your business data and processes to a different offering", not "network costs money" Correction: "Network costs obscene amounts of money" ~= "making it hard to move your business data and processes to a different offering"

oneplane 5y ago
That's not hard, just costly. Hard would be "here is your data in an obscure binary format and we are not going to tell you how to decode it". If you want to make a point of it being expensive, just say that it is expensive. Expensive isn't hard, it's just a calculation.
- pritambaral 5y ago
  > That's not hard, just costly. "High cost" doesn't mean "not hard". "Hard" isn't exclusively owned by engineers; business decisions can also be hard. > Hard would be ... Stop right there. You're awfully close to gatekeeping what "hard" means, but you have artificially limited your vision to "hard engineering problems". > Expensive isn't hard, it's just a calculation. Everything is a calculation. The cost of reverse engineering (or using an RE'd method) is a calculation. The cost of switching is a calculation. Deciding where to stop when making a pithy comment on a forum is a calculation. Here's a simple method to determine (in the context of lock-in) what's "hard": is it significantly preventing you from doing what you want? Maybe you have a lot of money to burn in getting your own data out from a predatory silo, so it's not "hard" for you, but consider that not everyone might be in the same boat as you.
  - oneplane 5y ago
    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 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'.
    - pritambaral 5y ago
      > 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. The world progresses. Language evolves (yes, even legal language, often understood to move glacially). But I'm not redefining anything here. "Vendor lock-in" is well understood at exec, management, and engineering levels and doesn't need to be artificially restricted to your limited reading of it. > I am writing about the ability to use a different vendor. The word "ability" also has meaning. It does not mean "absolute ability". E.g., Nearly every human has the "ability" to fly, through the modern technology of airplanes and the commonly provided services of airlines; but those (say, in countries like mine) who cannot afford a flight ticket are said to not have the ability to fly. > Not about runtime cost or integration. > Known runtime cost is part of normal OPEX. Migrating off of one vendor is not "runtime cost" or "normal OPEX". By making it more expensive to migrate away, a vendor raises OPEX costs of such an "abnormal" move. Such weaponisation of OPEX costs is made to price-out the option, and is absolutely a denial of ability for business who cannot afford or justify such high abnormal OPEX costs. ---- > 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. Look, no one is taking away your use-cases of the term "vendor lock-in". No one is disagreeing with you that those examples you cite absolutely are "vendor lock-in". But those are not the only cases or methods of it. While intentional incompatibility is a far too common method of creating vendor lock-in, it is not the only method. For example, vaporware by dominant vendors used to deny market access to competitors is an accepted form of vendor lock-in. > 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) I'm not trying to do any such thing. I have seen your "definition" and explained to you how the AWS egress tax is a means for promoting vendor lock-in, _within your definition_ of it. > Just for the sake of completeness, here is a random paper that explains it in extra detail I have read your "random paper"; it is a document explaining some history of economic literature. It does not define "vendor lock-in" (itself being careful to often use the phrase "lock-in" in scare quotes), but restricts itself to describing "lock-in by historical events". What it does define, though, is _path dependence_. And what does it define it as? "... a minor or fleeting advantage or a seemingly inconsequential lead for some technology, product or standard can have important and irreversible influences on the ultimate market allocation of resources ..."; or, simply put, "sensitive dependence on initial conditions." ---- > If an explanation, reference or paper isn't good enough for you, why bother posting at all? If an explanation, reference, or paper isn't even pertinent to the topic, and doesn't illustrate your point, why bother posting it at all?

oneplane 5y ago

That's not hard, just costly. Hard would be "here is your data in an obscure binary format and we are not going to tell you how to decode it". If you want to make a point of it being expensive, just say that it is expensive. Expensive isn't hard, it's just a calculation.

pritambaral 5y ago
> That's not hard, just costly. "High cost" doesn't mean "not hard". "Hard" isn't exclusively owned by engineers; business decisions can also be hard. > Hard would be ... Stop right there. You're awfully close to gatekeeping what "hard" means, but you have artificially limited your vision to "hard engineering problems". > Expensive isn't hard, it's just a calculation. Everything is a calculation. The cost of reverse engineering (or using an RE'd method) is a calculation. The cost of switching is a calculation. Deciding where to stop when making a pithy comment on a forum is a calculation. Here's a simple method to determine (in the context of lock-in) what's "hard": is it significantly preventing you from doing what you want? Maybe you have a lot of money to burn in getting your own data out from a predatory silo, so it's not "hard" for you, but consider that not everyone might be in the same boat as you.
- oneplane 5y ago
  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 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'.
  - pritambaral 5y ago
    > 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. The world progresses. Language evolves (yes, even legal language, often understood to move glacially). But I'm not redefining anything here. "Vendor lock-in" is well understood at exec, management, and engineering levels and doesn't need to be artificially restricted to your limited reading of it. > I am writing about the ability to use a different vendor. The word "ability" also has meaning. It does not mean "absolute ability". E.g., Nearly every human has the "ability" to fly, through the modern technology of airplanes and the commonly provided services of airlines; but those (say, in countries like mine) who cannot afford a flight ticket are said to not have the ability to fly. > Not about runtime cost or integration. > Known runtime cost is part of normal OPEX. Migrating off of one vendor is not "runtime cost" or "normal OPEX". By making it more expensive to migrate away, a vendor raises OPEX costs of such an "abnormal" move. Such weaponisation of OPEX costs is made to price-out the option, and is absolutely a denial of ability for business who cannot afford or justify such high abnormal OPEX costs. ---- > 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. Look, no one is taking away your use-cases of the term "vendor lock-in". No one is disagreeing with you that those examples you cite absolutely are "vendor lock-in". But those are not the only cases or methods of it. While intentional incompatibility is a far too common method of creating vendor lock-in, it is not the only method. For example, vaporware by dominant vendors used to deny market access to competitors is an accepted form of vendor lock-in. > 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) I'm not trying to do any such thing. I have seen your "definition" and explained to you how the AWS egress tax is a means for promoting vendor lock-in, _within your definition_ of it. > Just for the sake of completeness, here is a random paper that explains it in extra detail I have read your "random paper"; it is a document explaining some history of economic literature. It does not define "vendor lock-in" (itself being careful to often use the phrase "lock-in" in scare quotes), but restricts itself to describing "lock-in by historical events". What it does define, though, is _path dependence_. And what does it define it as? "... a minor or fleeting advantage or a seemingly inconsequential lead for some technology, product or standard can have important and irreversible influences on the ultimate market allocation of resources ..."; or, simply put, "sensitive dependence on initial conditions." ---- > If an explanation, reference or paper isn't good enough for you, why bother posting at all? If an explanation, reference, or paper isn't even pertinent to the topic, and doesn't illustrate your point, why bother posting it at all?