A national, open-source operating system could help reduce Canada’s dependence on the U.S. while improving security and saving a surprising amount of money.
This paper develops a comparative policy analysis of six state-sponsored Linux distributions (China, Russia, India, France, Germany and South Korea) using a dual total cost of ownership (TCO) + strategic autonomy analytical framework, benchmarked against Canada’s procurement landscape, laws and trade obligations.
Originality/value
This paper proposes a Canadian Free and Open Systems Foundation (Crown not-for-profit modeled on Germany’s Zentrum für Digitale Souveränität) alongside a three-phase implementation roadmap and five institutionally targeted policy recommendations. The proposal offers a generalizable middle-power template for reconciling digital sovereignty with open multilateralism, applicable to Australia, Japan, South Korea and Nordic states facing parallel dependencies.
So while the author mentions Debian, that is just an example. The actual recommendation is setting up a foundation to make those decisions after confirming it will meet the requirements + working with other countries on this
The actual recommendation is setting up a foundation to make those decisions after confirming it will meet the requirements + working with other countries on this
I also don’t have the full text. Is there anything in it about having this foundation lead from the front by using “strategically autonomous” software internally and experiencing the teething issues? Just dumping MS Office alone will be difficult. Did the full text go into the final thoughts on scale?
I added a link to the full PDF, it does seem to focus more on the rollout side
It doesn’t have the foundation try it internally, but it does call for a strategic rollout. The way I read it, the organization is only supposed to manage the transition and rollout, while people who are actually using computers for work will be the ones to test it. It will start with those who are less likely to be affected by any teething issues.
Pilot deployment targets risk-graduated workloads sharing four properties: web-first application stacks, low Microsoft 365 dependency, high political tolerance for transition friction, and existing institutional FOSS familiarity. The recommended pilot footprint comprises federal developer workstations (low compatibility risk, high FOSS familiarity), public-facing kiosks (single-application footprint), education ministries (existing FOSS deployments at the K-12 layer), and public library networks (Koha and Evergreen already deployed extensively).
This is also a part of the first phase, which IMO is more important:
A mandatory FOSS-first evaluation clause should be added to the Treasury Board Directive on the Management of Procurement for desktop and server refresh cycles. It should be framed as a technical-specification requirement rather than a nationality preference, replicating the EU’s GPA-compatible FOSS procurement architecture documented by Shaikh & Levina (2019).
He does also talk about MS Office & M365
the biggest user hurdle is rarely the operating system itself, which most users are unaware of, but the applications. Public servants are deeply entrenched in the Microsoft ecosystem and replacing MS Word and Excel with open-source alternatives like LibreOffice can be challenging for some users. Although LibreOffice has overall good functionality, minor changes may be needed, for example in formatting, use of macros or assuring the fonts users want are available
Application incompatibility is rated High likelihood, as Microsoft 365 lock-in is the primary operational constraint. Empirical FOSS migration research demonstrates that web-first sequencing combined with compatibility layers resolves the majority of incompatibilities at the application layer rather than requiring wholesale rewrites (Ven & Verelst, 2011). To minimize this primary risk the following migration sequence can be used (Hauge, et al., 2010):
Inventory applications by dependency class.
Prioritize browser-based and cross-platform applications.
Containerize or virtualize legacy Windows applications.
Replace Active Directory dependencies with open identity standards where feasible.
Maintain Windows virtual desktops for exception cases during the transition
The author does discuss that actually
Here is the study it is referring to, which the author put out last week
(although I don’t have the full text right now): https://www.emerald.com/dprg/article-abstract/doi/10.1108/DPRG-06-2026-0347/1400436/Open-source-digital-sovereignty-the-case-for-a?redirectedFrom=fulltextEDIT: Full paper here: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7585538
So while the author mentions Debian, that is just an example. The actual recommendation is setting up a foundation to make those decisions after confirming it will meet the requirements + working with other countries on this
I also don’t have the full text. Is there anything in it about having this foundation lead from the front by using “strategically autonomous” software internally and experiencing the teething issues? Just dumping MS Office alone will be difficult. Did the full text go into the final thoughts on scale?
I added a link to the full PDF, it does seem to focus more on the rollout side
It doesn’t have the foundation try it internally, but it does call for a strategic rollout. The way I read it, the organization is only supposed to manage the transition and rollout, while people who are actually using computers for work will be the ones to test it. It will start with those who are less likely to be affected by any teething issues.
This is also a part of the first phase, which IMO is more important:
He does also talk about MS Office & M365