Open Source advocates often use the image of a physical diary with a lock to raise awareness about the nature of lock-in. Imagine you have a diary and you routinely use it to leave a written trace of your ideas, musings, encounters with interesting people, food recipes, beautiful things you have seen… This is content created by you, and you can access it any time. You just need to open your diary and start reading. Some of these diaries come with a physical lock. The idea is that you may not want to share some of this information widely, even if by accident. So you lock your diary and take the key with you. In that way, even if somebody comes across your diary, they do not have access to your sensitive information. Now imagine that the owner of that key were a company, and that you needed to pay them a monthly fee so they lent you the key every time you wanted to access the very content you had created. This may sound ludicrous, but it is exactly what we agree to when we use proprietary software instead of a physical diary to store our work. We have normalised a situation in our digital lives which we would not accept at all in our “analogue” endeavours. Cloud lock-in is a particularly extreme version of this power shift, where your diary is not even sitting physically with you anymore. For example, if your organisation is using MS Exchange Online for email, all your messages are on a server “somewhere” and good luck if you ever try to migrate away from it: MS does not provide an easy way to mass-export your content to some standard format.
A typical user
Most of the people I know use proprietary software without much concern for lock-in. Let us take the example of MS Office. It is a well-designed and maintained software suite. Its users are happy with it for the most part. Some of them have automated large parts of their work using e.g. macros and other time-saving features in Excel. Large spreadsheets with lots of automation are the main way of organising and tracking work in many places. The IT teams in companies typically negotiate licence and support fees with Microsoft every few years, and often provide a bit of local support as well.
Once I was talking with one of these happy users, a person I respect a lot, and after having gone through lock-in risks and the pros and cons of MS Office, he looked at me with a friendly-condescending smile and asked: “do we really have a problem?” It made me think. His job has nothing to do with IT. He needs tools that will help him, or at least not get in the way, and he is happy to pay for them. Because MS Office is a bit of a de facto standard as far as office suites go, he does not notice lock-in at all in his daily work. In his company, they have had the occasional struggle negotiating licence prices with Microsoft but in the end they agreed on what he considers a reasonable price. The Free and Open Source Software (FOSS) alternatives to MS Office have been lagging in terms of features and maturity for years. He is convinced that, were he to migrate, his productivity would take a serious hit. He understands the current discussions on technological sovereignty, but he is not prepared to sacrifice his very concrete short-term objectives for some vague long-term vision he has difficulty relating to.
As I ponder this case, which I think is very representative of a typical user of proprietary software, I cannot help but feel a bit torn. We “raisers of awareness” are bringing bad news to otherwise fully happy people. We should avoid being too grumpy about the state of the world, and instead focus on all the great things we can do together to make it better. But I digress.
The “science” of risk assessment
When we try to evaluate and control risk at work in the context of a project, we do a relatively simple exercise. On one hand, we try to quantify the probability of something bad happening. On the other hand, we try to assign a number which expresses the impact that bad thing happening would have on the project. The bigger the negative impact, the bigger the number. We then multiply these two numbers: probability and impact. If the result is above a certain threshold, we need to do something about that particular risk factor, something that will drive down the probability, the impact or both.
Can we apply this same methodology to assess our exposure regarding lock-in? Not really. The impact could be quantified and in many cases would be in the “catastrophic” category. Imagine instantly losing access to all those carefully crafted spreadsheets and macros. Or Microsoft allowing third parties to look at your private documents in order to comply with US law, as happened in a recent case.
The probability, however, is much harder, probably impossible, to evaluate meaningfully. A sharp increase in licence costs could be the result of changes in management, priorities and other factors which have very little, if any, correlation with past behaviour. Trying to predict future prices based on past prices is probably worse than admitting the impossibility of the exercise, because it can give you a false sense of security which can drive wrong decisions. One assumption you can make is that a vendor will not push the price beyond the threshold of pain for a client, but that is a very slippery concept. What is that threshold and do you really want to find out?
There are other things that could go wrong besides a sharp increase in price. For example, some software could be added to the list of items under export control, as happened recently with some AI models. Or if you are a judge in the International Criminal Court (ICC), the US Government could decide that you should stop having access to technology developed in the US, again something that recent events illustrate. All these sources of risk share a common feature: the probability of them happening is essentially impossible to quantify.
It seems to me that the most rational way to manage them is to start preparing an exit strategy, provided that preparation has a reasonable, for some definition of “reasonable”, cost. This is the crux of the matter. Most people understand the reasoning above, but think the way out is too costly, so they choose, more or less consciously, to accept this unquantifiable risk.
Some numbers
Making quantitative assessments and predictions is always risky, but let us make things more concrete by injecting some numbers. The reader is invited to “fork” this article, in the best tradition of Open Source, and modify the reasoning and the numbers to see where that takes us. I am not claiming these numbers are exact, just using some educated guesswork to help make the argumentation more concrete and hopefully more relatable. If you are working in a medium-big company, say with a few thousand employees, chances are your company is paying around 1 M€/year for MS Office licences and support. Let us also assume (and this is the wildest and least justifiable assumption I am making) that 90% of that money is not being used to make MS Office better for you. Let us say that a company providing development and support to you for a perfect FOSS equivalent could do that for 100 k€/year. If this number sounds way off, remember that you are not the only client for this same product. To simplify things with round numbers, and again for the sake of facilitating argumentation, let us assume that creating an average job in an average EU country, including salary and benefits, costs 100 k€/year too.
An opportunity
Now imagine your company is a bit concerned about the lock-in risks described above, and decides to invest 100 k€/year for five years on a parallel path, getting support for an office FOSS tool (LibreOffice, Collabora, Euro-Office…) while also keeping its MS Office contract running. Why five years? Because in this hypothetical World of Wonders, where Open Source advocates are never grumpy, after five years the FOSS tool has caught up in features and quality, or at least it is deemed “good enough”.
Let us take stock of the situation at that point in time: the company has paid an extra 10% for office software each year, which means an additional cost of 500 k€. If, as a result of that, it can fully migrate to the FOSS suite in a smooth way, then it will start saving 1 M€/year right away, which means it will recoup its investment in six months.
So this seems to make sense to the company in this story. But it makes even more sense if you consider the EU as a whole, especially if the FOSS provider is European. After five years, the FOSS alternative has become the de facto standard, so newcomers do not need the extra initial investment incurred by the “pioneers”. This scheme also creates new jobs in the EU, and not just any job, but the kind that guarantees long-term sovereignty for our digital infrastructure. The order of magnitude is one new job for each medium-sized company using the suite.
My estimate of five years to catch up is more realistic if many companies take the same strategic decision to invest in FOSS. Since this plan, if executed correctly, clearly solves a problem for the EU, and since companies could have an incentive to just wait and let others do the initial investment, shouldn’t the member states contribute to it? They could do so by investing in FOSS themselves or through other methods. Investment could be direct (becoming users of the services of companies supporting FOSS) or indirect (e.g. allowing and encouraging the civil servants in administrations to spend part of their time contributing to FOSS).
In the scenario outlined here, you get more sovereignty and save money at the same time. This looks too good to be true until you realise that both aspects are tied together: you save money because you are sovereign, and you were spending more money before because you were not sovereign. Sovereignty becomes the cause and savings are just one among several positive consequences of that sovereignty. I mention this because we have seen in the past unsuccessful efforts to migrate to FOSS and my contention is that having a misguided objective (short-term savings) instead of the larger goal of achieving sovereignty played an important role in those failed attempts.
Let me now circle back to the initial question. Betteridge’s law of headlines states that “any headline that ends in a question mark can be answered by the word no.” This article is no exception. Seeing the momentum already gathering in Europe and assuming the relevant bodies in the EU support it, I do not think we have a problem. What we have is a great opportunity.