4 ms·

Lock-in is if the amount of work you need to put in to transfer your stuff to $competitor is big when you want to leave. When there is one company that maintai

by atoav 4y ago

Lock-in is if the amount of work you need to put in to transfer your stuff to $competitor is big when you want to leave. When there is one company that maintains a rooms media tech rack with media switchers and DSPs of another company that only provides access to "certified" companies and the first company sits on the source code they programmed for you, so you have to run to them with any slight change of the system you use, because you neither own the source code, nor do you have access to the softwar used to program the devices, that is lock-in. Yeah you could swap out that media switcher with one from a more open company, but then you'd have to swap out 50k€ of other gear, that is "compatible" to that switcher (and to nothing else). I am sure github is making it totally easy to migrate all of what you do on their platform to e.g. gitlab. /s

FooBarWidget 4y ago
One way to reduce switching cost is by not making use of much of the value provided by $CURRENT_VENDOR. For example you can treat AWS as merely a virtual machine and object storage provider, and not making use of their managed databases, AI services, message queues, etc. When you need those latter things, you build them yourself on top of virtual machines and object storage. But of course, most people take one look at this calculation and decide that it's not worth it to build so much things yourself just so that you can easily switch to another cloud provider. They rightly view it as a waste of time. I've seen many companies who had the aspiration to be "multi-cloud" from the beginning and being able to switch to another provider with ease, and every time this aspiration fails due to business pressures. There's always something more important to do than building your own cloud-agnostic database orchestration system, or your own cloud-agnostic message queue. You're complaining that Github provides features. Yes making use of those features lock you in in the sense that it makes switching to another provider harder. But the world is not better when Github doesn't provide those features at all.

by atoav 4y ago

FooBarWidget 4y ago

One way to reduce switching cost is by not making use of much of the value provided by $CURRENT_VENDOR. For example you can treat AWS as merely a virtual machine and object storage provider, and not making use of their managed databases, AI services, message queues, etc. When you need those latter things, you build them yourself on top of virtual machines and object storage. But of course, most people take one look at this calculation and decide that it's not worth it to build so much things yourself just so that you can easily switch to another cloud provider. They rightly view it as a waste of time. I've seen many companies who had the aspiration to be "multi-cloud" from the beginning and being able to switch to another provider with ease, and every time this aspiration fails due to business pressures. There's always something more important to do than building your own cloud-agnostic database orchestration system, or your own cloud-agnostic message queue. You're complaining that Github provides features. Yes making use of those features lock you in in the sense that it makes switching to another provider harder. But the world is not better when Github doesn't provide those features at all.