If you’ve been reading my other posts you know I love Open Source… and also that I hate lock-in with a great passion. Maybe this stems from the fact that I was born in the Soviet Union, where many choices were taken away “for your good”, or maybe I’m just a reasonable human being. In any case, I believe any kind of lock-in sucks and you should strive to avoid it when practically possible.

At the same time, one may say there is always some form of lock-in as we make our life choices since change comes at a cost. For example, if you move to an area, buy a house, make local friends, and discover all the good places to eat, you create a kind of lock-in for yourself. Moving to a different place will come at a cost, yet the choice of whether to make a switch is yours and the costs and burdens are natural.

An interesting property of our lock-in in life is that we tend to have a choice about what part of life we want to change – if you do not like your house but you like your area, you can usually get a different one; if you do not like the hairdresser, there are probably tens of others in the area.

Open Source Software, at its best, offers a similar experience – you tend to have a variety of choices in a well-developed ecosystem, allowing you to make changes as you see fit.
Let’s take a look at practical lock-in avoidance and the requirements to minimize lock-in and maximize freedom of choice in our Technology platform. I think it comes down to just three things:

Commodity Foundation

Software needs to run somewhere, whether it’s on physical servers you own or in the cloud. In practice, “Open Source” is not as important here as being commoditized. In the early days of the Internet, the cost of building the Web was dramatically lowered and lock-in was avoided because there were many commoditized hosting providers, as well as server options – it did not really matter if you bought from Dell, HP, IBM, Supermicro, or others to run your software, it was basically a commodity. Now, in the age of the cloud, we often do not think (or often do not even know) about hardware vendor specifics, but the principles of commodity still apply. If I’m using Kubernetes, I don’t care as much about which Cloud Vendor it’s running, or if I’m using Terraform/OpenTofu to provision my infrastructure, the specific cloud vendor matters little to me. This, of course, only works if you stick to commoditized cloud services, which, in my opinion, is a smart thing to do.

Open Source Software

What do you run on that Commodity Foundation? Of course, it’s Open Source Software – Linux, Kubernetes, PostgreSQL, Apache, Nginx. If you have non-commoditized parts of your technology infrastructure implemented using Open Source software, you maximize your freedom, minimize lock-in, and, over time, cost. Remember, commercial vendors are ultimately there to maximize returns for their shareholders, which means if they have “leverage,” they will inevitably make you pay more. The only way to avoid this is to ensure you have the leverage of choice, not them.

Multiple Vendors

The third pillar is having multiple vendors. In reality, few companies, especially larger ones, can just take Community Open Source software “from the wild” and deploy, support, and maintain it using their in-house experts. What they need is to work with someone (a Commercial Vendor) to help them with their needs. If there is only one vendor, you do not really have a choice, and there is no balance of power; rather, that single vendor has a lot of leverage against you. This is what is so practically problematic with the recent breed of non-competitive Source Available Licenses like SSPL – they are focused on restricting your vendor choice and creating a monopoly, at least in some areas.

Avoiding lock-in completely is not always practical, and I recognize that the most practical choice in some cases may be to lock in and hope your Benevolent Overlord continues being benevolent (hello to my Apple-loving friends). Yet, I hope this simple framework will help you reduce your practical lock-in when it is important for you.

 Subscribe via RSS