Back

Detaching from US systems, 2/x

Right now it is probably "safe" to use US-made systems, with the caveat that trust in US systems should have eroded already after Snowden's NSA revelations.

Detaching from US systems, 3/x

Trump's foreign policy towards United States' former democratic allies has been hostile and he went to bed (metaphorically, I believe) with the Russian dictator Vladimir Putin. He already used his powers once to pressure a commercial, US-based satellite image provider Maxar to stop providing data to the Ukraine army once. He may do it again at a whim.

Detaching from US systems, 4/x

At some later point it is very likely that he will weaponize the ubiquitous US companies such as Apple, Google, Microsoft to reach foreign policy goals. None of us Europe, Canada or elsewhere are not really ready for it and that's why we must prepare to avoid a huge shock later.

Detaching from US systems, 4/x

In a later post I will try to outline some principles one can use to start planning a "decoupling from the US" operation on personal and organizational levels.

Detaching from US systems, 6/x

There are two principles I'm going to follow when decoupling myself (and my company) from US-based services: "prefer open source", "avoid SaaS when possible" and "prefer european" (or in a wider sense: "made in a democratic country").

Detaching from US systems, 7/x

Open source software gets you multiple benefits. First, it is very hard to hide any backdoors or hostile code inside open source software, as the code is in plain sight for everyone. Morever, in high-profile projects especially the code acceptance criterions tend to be pretty strict.

Detaching from US systems, 8/x

It would be very difficult for the US administration (or any other such party) to get malicious code into a well-managed open source project. That said, strictly speaking
you cannot trust pre-built executables: there's no way (afaik) of telling whether the executable actually is based on the source code of the project. This makes "commercial open source" more vulnerable to manipulation by political actors.

Detaching from US systems, 9/x

My second principle is to "avoid SaaS when possible". The first reason is that SaaS applications are usually very inflexible. The SaaS business model is usually tied to having a high volume of customers. This, in turn, tends to steer SaaS products in their early development stages towards high degree of standardization or "dumbing it down"

Detaching from US systems, 10/x

Some of the more advanced SaaS solutions are very configurable. This configurability comes at the cost of high complexity. A good example is the Atlassian Suite which you can adapt to your needs very well, but only if hire a specialist to do it for you. Or, you can spend a ungodly amount of time researching and trying things out yourself.

Detaching from US systems, 11/x

The second reason to avoid SaaS is basically: "you have not idea what it is doing under the hood". Unlike with traditional "run it yourself" closed source software with SaaS you don't even have access to the executables. In other words, you have no visibility whatsoever what the SaaS service is doing. This, combined with a clear political risk, is not good at all.

Detaching from US systems, 12/x

Getting rid of SaaS services, and in particular the more advanced US-based ones, is going to be hard. A large percentage organizations in Finland and elsewhere in Europe depend on Microsoft 365 for example. Development companies tend to use the Atlassian suite and Slack. Some depend on Google Workspace. And there are many others we use daily.

Detaching from US systems, 13/x

There are few if any drop-in replacements for these leading US-based SaaS services. So, you have to cobble together your own solutions based on a mix of non-US SaaS, self-hosted applications and desktop applications.

Detaching from US systems, 15/x

The EU has had the "Digital sovereignity for Europe" think tank for a while:

https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2020)651992

This has been a step in the right direction, but the dominance of US software companies means that most of the services we use are American, not European.

Detaching from US systems, 16/x

How can you plan your migration away from US-based systems and services? I can immediately see at least two strategies: 1) minimizing the amount of money flowing to the US, 2) minimizing the long-term risk caused by use of US systems.

#boycottamerica
#boycottus

Detaching from US systems, 17/x

Migration to European alternatives is complicated by several things: networks effects, vendor lock-in and in lieue of those, just the amount of work needed to do the migration.

Detaching from US systems, 18/x

Network effect means that the value of a service or product grows as its userbase grows. Good examples are social media services and messaging systems. As more and more people are on the platform, it becomes increasingly difficult to leave without losing something that is of value to you due to #networkeffect.

Detaching from US systems, 19/x

Creating #vendorlockin is a classic strategy used by software companies. They do this by making it difficult to get your data out or by intentionally breaking interoperability with other systems.

Detaching from US systems, 20/x

For example, Microsoft used their dominant marketshare to create #vendorlockin in operating systems (Windows), office software (Microsoft Office) and web browsers (Internet Explorer) to sabotage their competitors They did this by intentionally breaking standards compliance (HTML), not having standards (.doc format) and by using "leverage" (i.e. extortion) to force PC manufacturers to pre-install Windows on every system despite availability of alternatives.

Detaching from US systems, 21/x

You can also end up in a #vendorlockin all by yourself. This can happen unintentionally when you add a lot of value on top of a solution. For example, if you all the bells and whistles in Microsoft 365 or Azure it will be hard for you to decouple yourself from them later. To avoid this prefer solutions that are not vendor-specific whenever you can.