In a previous article, Søren Hauberg argued that we should reduce our dependence on U.S. software. I would like to start a discussion focused on concrete solutions and the challenges involved in making such a shift.

Today, Microsoft products dominate the corporate world, which naturally supports using Microsoft (or other U.S.-based) solutions at DTU. However, the risks associated with relying on U.S. vendors are increasing. In principle, U.S. authorities or companies could restrict access and effectively shut down DTU—or even Denmark—at any time.

At the same time, alternatives such as OpenOffice are not sufficiently modern or widely used, and LaTeX interfaces still feel like something from the 1990s. Neither OpenOffice nor LaTeX represent tools commonly used in industry, and relying on outdated or niche tools would be a missed educational opportunity. Simply replacing Microsoft Office is not enough to make a meaningful difference.

One possible direction could be services like Proton Mail/Drive/Office/Authentication/AI. As a Swiss company, Proton may pose fewer geopolitical risks, although I do not know the details of their server infrastructure. However, these tools do not solve the dependency on Windows itself—which is arguably the core issue. Like it or not, many scientific instruments run on Windows, and that remains a significant limitation. Proton’s Linux support also appears limited, though using the tools through a browser might mitigate this.

A more robust long term approach could be to diversify the operating systems used at DTU. We already do this to some extent, but increasing Linux adoption—especially within administrative systems—could strengthen resilience. This would of course require investment in support and training. Unfortunately, some administrative processes currently rely on VBA and Microsoft Office, such as reporting student data.

Additional question: Are we primarily running Windows servers or Linux servers? Should DTU maintain its own server capacity at all, or should some of it be outsourced to providers such as Proton or similar European solutions?

I propose that we begin testing alternative solutions and allocate resources to support this exploration. Re training staff and adapting workflows will cost money, but so will continuing to use suboptimal or high risk software ecosystems.

A tip from a former software developer: any testing must be carried out by a representative group of real end users—administrative staff, technicians, early career researchers, senior researchers, etc. IT specialists can validate the technical underpinnings, but they are not reliable proxies for everyday users.
 

The original text was written by me, polished using AI (which also is an issue here)  and verified by me before submitting.

Martin Dufva DTU Health Tech
Associate Professor
Head of studies- BSc Human Life Science engineering
Head of studies – MSc Quantitative biology and disease modelling