Chapter 6: Software Sovereignty: Building NepalOS

The Invisible Tax

Every year, the Government of Nepal is caught in a costly software trap: paying for software it does not own, cannot inspect, and cannot modify, or running unlicensed copies that expose the state to severe security risks.

Historically, due to budget constraints and lax enforcement, many government offices relied on unlicensed or pirated software. The National Cyber Security Center (NCSC) has repeatedly warned that this dependency leaves public systems open to server crashes, data theft, and hacking. To mitigate these vulnerabilities, ministries have begun procuring genuine software, such as the Ministry of Finance's recent tenders for licensed Microsoft Windows and Office. But this shift toward compliance reveals the financial cost: the government is forced to send millions of dollars in foreign currency to Silicon Valley just to keep its computers running legally.

The exact figure is surprisingly difficult to pin down. No single ministry tracks the total national expenditure on proprietary software licenses. But the potential spending is everywhere. Microsoft Windows runs on government computers in every ministry, every district office, every public school that has a computer lab. Microsoft Office handles the documents. Oracle databases store records. Google services handle email for countless agencies and institutions. Each of these products requires a recurring license fee, paid in foreign currency, to a company whose headquarters, data centers, and legal jurisdiction are thousands of kilometers from Kathmandu.

This is not a vulnerability unique to developing nations. In Europe, 74 percent of publicly listed businesses rely on US-based email and productivity suites, primarily Google and Microsoft. In Ireland, that dependency is 100 percent. Spain's energy and banking sectors are entirely dependent on foreign tech. The European Union spends roughly €20 billion annually on proprietary collaboration suites, which is capital that flows directly out of the regional tech economy to Silicon Valley.

For Nepal, running a trade deficit exceeding NPR 1,267 billion in nine months, the ongoing drain of software licensing fees represents more than just inefficiency. It is capital that could be invested domestically. In programmers. In infrastructure. In building something that Nepal actually owns.

This dependency is not unique to the public administration. Nepal's commercial sector, particularly its banking and financial institutions, operates on a similar treadmill of proprietary licensing. The core banking systems (CBS) powering the country's commercial banks, the cloud infrastructures hosting private databases, and the CRM suites used by local enterprises are almost exclusively imported from multinational vendors. Every year, millions of dollars in foreign currency are sent abroad in licensing fees to entities like Oracle, Microsoft, and specialized global financial software firms. This private-sector license drain compounds the national trade deficit, further bleeding capital that could otherwise fund local software customization, capacity building, and sovereign development.

The financial argument for open-source alternatives is straightforward. The security argument is more urgent.

The Economics of Sovereignty: Quantifying the Opportunity

The exact figure of Nepal's annual proprietary software expenditure remains unquantified (no ministry tracks it), but we can estimate it from comparable data. Nepal operates an estimated 500,000 government and public-sector computers. If each machine runs Windows with a Microsoft 365 enterprise license, the annual cost per workstation ranges from $100 to $300 (NPR 13,500 to 40,500). Across 500,000 machines, that is $50 million to $150 million per year flowing abroad, or NPR 6.7 billion to 20 billion, depending on license tiers and volume discounts.

That estimate excludes Oracle database licenses, Google Workspace subscriptions, proprietary ERP systems, antivirus contracts, and vendor support agreements that further compound the drain. The true figure is almost certainly higher.

What does Nepal get for that money? A dependency it does not control, on software it cannot inspect, maintained by companies whose legal obligations lie elsewhere. What would Nepal get if it redirected even half of that expenditure?

Jobs. The Utrecht University study of ten commercial open-source companies found that 80 percent of their costs are personnel: salaries for employees, support staff, and developers. Every rupee spent on domestic OSS services pays Nepali salaries. Every rupee spent on Microsoft licenses pays Redmond shareholders.

A Total Cost of Ownership comparison makes the case concrete:

The 5-year net savings of $195M to $645M represent capital that could fund NepalOS development, train thousands of engineers, and build a self-sustaining domestic software industry, while simultaneously reducing the trade deficit and eliminating a structural dependency.

The financial argument is not theoretical. It is arithmetic. But the political argument is harder: someone must approve the migration, manage the transition, and survive the inevitable complaints when a keyboard shortcut changes. That is the challenge the rest of this chapter addresses.

The Security Problem You Can't Audit

When a government runs its critical infrastructure on proprietary software, it operates on trust. Trust that the vendor has not introduced vulnerabilities (deliberately or accidentally) into code that the government cannot read. Trust that the vendor will not change licensing terms, raise prices, or discontinue support at an inconvenient moment. Trust that the vendor's own security practices are adequate, despite the government having no ability to verify them.

That trust has been tested, repeatedly, worldwide. In 2020, the SolarWinds breach demonstrated that even the US government's own agencies could be compromised through software supply chain attacks on proprietary products. In 2023, a Microsoft cloud breach exposed email systems across multiple US federal agencies. These were not attacks on obscure software. They were attacks on the exact products that Nepal's government relies upon.

For a country navigating complex geopolitical relationships with India, China, and the West, running sovereign government systems on software subject to a foreign legal jurisdiction introduces a specific category of risk. If geopolitical tensions escalate, through sanctions, trade disputes, or diplomatic crises, software licenses can become leverage.

Even when data is stored locally, legal jurisdiction often overrides geography. For instance, the US CLOUD Act compels American tech companies to hand over data regardless of where their servers physically reside. Microsoft representatives recently admitted under oath in France that they cannot guarantee EU data won't be handed over to US authorities upon request, exposing the limits of localized hosting. This has led to the phenomenon of "sovereign washing," where US companies market "sovereign cloud" solutions in Europe while remaining fundamentally bound by foreign law.

Open-source software eliminates this vulnerability at the architectural level. When the source code is public, it can be audited by domestic engineers. When the software is free to use and modify, it cannot be withheld as a geopolitical tool. When the platform is maintained by a global community rather than a single corporation, there is no single point of failure and no single entity that controls access.

FOSS Nepal: Twenty Years of Advocacy

The idea of open-source adoption in Nepal is not new. The FOSS Nepal Community has been advocating for it since 2004, spanning over two decades.

The community's arguments have always been sound: lower costs, better security, freedom from vendor lock-in, the ability to customize software for local needs including Nepali language support. Community members contributed to the localization of LibreOffice into Nepali. They organized workshops, conferences, and training sessions. In 2025, Kathmandu hosted UbuCon Asia, a major international Ubuntu community conference that signaled Nepal's growing integration into global open-source networks.

This advocacy even led to concrete software development. In 2013, a team of Nepali developers in Chitwan built Chitwanix OS, the country's first home-grown Linux distribution. Based on Ubuntu, Chitwanix featured a custom-built desktop environment called Sagarmatha (a fork of Cinnamon) and came "out-of-the-box" ready with pre-installed productivity tools. Its version 1.0 (codenamed "Kadey Vyakur" after Nepal's endemic Spiny Babbler) was released on Software Freedom Day in 2013, followed by version 1.5 ("Khukuri") in 2014. Despite its initial promise and local language support, Chitwanix OS was eventually discontinued. The project serves as a crucial case study: it failed not due to technical deficiencies, but because it lacked the commercial support, institutional backing, and procurement mechanisms required to sustain public software projects, representing a gap that the commercial open-source engines described in Chapter 7 seek to resolve.

Despite these efforts, actual adoption within government institutions has been limited. The reasons are familiar to anyone who has worked in institutional technology:

Inertia. Government workers know Microsoft Office. They were trained on it. Their documents are in Microsoft formats. Switching to LibreOffice means retraining, reformatting, and an uncomfortable period where everything takes longer.

Vendor relationships. Proprietary software companies invest heavily in government relationships through sales teams, executive briefings, sponsored events, and licensing deals that bundle training and support. Open-source alternatives have no equivalent sales force.

Fear of the unfamiliar. Decision-makers in government IT departments are risk-averse by nature. Choosing Microsoft is safe; if something goes wrong, you hired the world's largest software company. Choosing LibreOffice is perceived as a risk; if something goes wrong, you chose the free option.

Lack of local support infrastructure. When a Microsoft installation breaks, there is a support contract to call. When a LibreOffice installation breaks, who do you call? The absence of a professional support ecosystem for open-source software in Nepal has been a real barrier, not an imagined one.

These obstacles are real. They have stalled open-source adoption for twenty years. But two things have changed that make the next attempt fundamentally different from previous ones.

What Changed: AI as a Development Force Multiplier

The first change is artificial intelligence.

Historically, developing and maintaining a customized Linux distribution required a large team of elite systems programmers who understand C, kernel internals, device driver architecture, and the arcane details of system-level software. Nepal has talented software engineers, but the pool of kernel-level developers is small. The expertise required to fork, customize, secure, and maintain an operating system was simply beyond what the domestic workforce could sustain.

AI coding tools have changed this equation dramatically. Advanced large language models have demonstrated the ability to read kernel code, identify vulnerabilities, write patches, and explain complex system behaviors in ways that were impossible even two years ago. An engineer working with an AI coding assistant can accomplish in hours what previously took days. A small team of ten to twenty skilled engineers, equipped with AI tools, can do the work that previously required a team of fifty or more.

This does not mean AI writes the operating system. That is a misunderstanding. It means AI lowers the barrier to entry for systems-level work, making it feasible for Nepal's existing engineering talent to undertake projects that would have been impractical without a much larger workforce.

The second change is institutional. The $90 million World Bank and ADB digital transformation funding (discussed in Chapter 8) creates a financial mechanism to actually fund the migration. Previous open-source advocacy failed in part because there was no budget for the transition, including funding for training, support contracts, and the initial productivity loss that any major platform migration entails. That funding now exists.

NepalOS: What It Would Actually Be

Let us be specific about what a sovereign Nepali operating system means in practice, because the concept sounds grander than the technical reality.

NepalOS would not be an operating system built from scratch. Nobody builds operating systems from scratch anymore, not even China or Russia. It would be a customized distribution of an existing, mature Linux platform, most likely Debian.

Debian is the obvious choice for several reasons. It has been in continuous development since 1993. Its package repositories contain over 59,000 software packages. Its security track record is extensively documented and audited. It is already the foundation for dozens of government-adopted Linux distributions worldwide.

What customization means in practice:

Localization. Full Nepali language support throughout the interface: not just a language pack bolted onto an English system, but native support for Devanagari script in system menus, file management, input methods, and accessibility features. Integration of Nepali NLP models (potentially trained on the national HPC clusters discussed in Chapter 5) for spell-checking, autocomplete, and text-to-speech.

Cultural Preservation: Scripts and Regional Dialects. Nepal is home to over 120 spoken languages and a rich diversity of indigenous scripts. Traditional commercial software providers have zero financial incentive to support these marginalized languages, leading to their digital exclusion. A sovereign operating system provides a unique opportunity to preserve technology but save culture. NepalOS should build in native support for regional languages such as Tamang, Newari (Nepal Bhasa), Tharu, Gurung, and Magar. Furthermore, it should package open-source Unicode fonts and input systems for scripts like Ranjana Lipi, a script of deep historical and artistic significance that has historically lacked native Unicode blocks. By packaging open-source font projects like EkType's Nithya Ranjana (which maps Ranjana characters to Devanagari and Newa Unicode points under the SIL Open Font License), NepalOS enables the digital preservation of historical documents and allows indigenous scripts to be natively typed and read in the public sector.

Pre-installed applications. LibreOffice for document creation (compatible with Microsoft Office formats). Nextcloud for secure, locally-hosted cloud storage, which ensures that government files never leave Nepali servers. Firefox ESR (Extended Support Release) configured for secure browsing with appropriate certificate management.

Security hardening. Full-disk encryption by default. Mandatory access controls for multi-user government environments. Hardened kernel configurations reviewed by domestic security experts. Regular security patches managed by a dedicated team rather than relying on a foreign vendor's release schedule.

Hardware compatibility. This is where most sovereign OS projects stumble. The system needs to work with the printers, scanners, biometric devices, and networking equipment already deployed across thousands of government offices. A beautiful operating system that cannot print is useless.

Quantum-ready architecture. There is a less immediate but equally important consideration: NepalOS should be designed from the start to be migratable to post-quantum cryptography. Quantum computers capable of breaking current public-key encryption (RSA, ECC) are likely within the 10- to 15-year horizon. A government operating system deployed today will still be running when that transition is necessary. NepalOS should use cryptographic libraries that support hybrid classical-quantum algorithms and allow seamless key replacement, ensuring that Nepal's sovereign infrastructure does not need to be rebuilt from scratch when the quantum transition arrives.

The Complete Open-Source Stack for Government Operations

NepalOS is the foundation, but a foundation alone is not a house. The government needs a complete software ecosystem, with every layer of its digital infrastructure running on sovereign, auditable, open-source code. The European experience provides a mature reference architecture. Germany's openDesk platform bundles Nextcloud, Collabora, XWiki, OpenProject, Jitsi, Element, and Univention Nexus into an integrated, Kubernetes-based deployment that can run on-premises or in sovereign clouds. CollabNext, a federated European initiative, distributes different stack layers across multiple providers to avoid single-vendor lock-in.

Nepal does not need to adopt these European systems wholesale. But the architectural principle is sound: a sovereign stack is not a single application but a coordinated layer of open-source components, each replacing a specific proprietary dependency.

The following table maps Nepal's government IT requirements to specific, proven open-source alternatives:

This is not a hypothetical list. Every tool named above is in active production use by governments, enterprises, and institutions worldwide. The European Union's openDesk initiative has already integrated these components into a deployable platform. Nepal does not need to invent the stack. It needs to localize, harden, and deploy it.

The critical integration layer is identity management. A single sign-on system (built on Keycloak or Univention) allows government employees to authenticate once and access any application in the stack. Without this, each tool becomes another username and password, another silo, another integration headache. With it, the stack becomes a unified, coherent platform where switching from LibreOffice to Nextcloud to OpenProject is seamless.

The economic multiplier of this stack deserves emphasis. When the government deploys ERPNext instead of SAP, the customization, hosting, training, and support work goes to Nepali companies. When it deploys Nextcloud instead of Google Workspace, the annual subscription or support contract fees stay in Nepal. The stack is not just sovereign. It is an engine for domestic job creation at every layer.

Lessons from Those Who Tried Before

Nepal would not be the first country to attempt a sovereign Linux distribution. The track record of previous efforts is both instructive and sobering.

Denmark's 2025 Migration. The strongest proof that sovereign migration is possible comes not from a developing nation, but from Denmark. In mid-2025, the Danish Ministry for Digital Affairs initiated a phased replacement of Microsoft products with open-source tools as part of a DKK 740 million digitalization strategy. The explicit goal, as stated by Minister Caroline Stage, is to achieve "digital sovereignty" and reduce reliance on American technology. Following the Ministry's lead, major cities like Copenhagen and Aarhus are exploring similar shifts.

Germany: Schleswig-Holstein. Following Munich's troubled history, the German state of Schleswig-Holstein launched an "Open Innovation and Open Source Strategy" to migrate 30,000 employees from Microsoft to Linux and LibreOffice. The project includes structured macro-migrations, training programs, and direct contributions back to the LibreOffice codebase to fix accessibility issues.

Russia: Astra Linux. Russia developed Astra Linux specifically for military, intelligence, and classified government use. Built on Debian, it features mandatory access controls and hardened security configurations. Astra Linux has been successfully deployed across Russian defense and intelligence agencies, though its success was driven by a genuine national security mandate backed by substantial funding.

India: BOSS Linux. Bharat Operating System Solutions (BOSS), another Debian derivative, was deployed across Indian government agencies and educational institutions. Adoption has been meaningful but uneven, as many agencies still prefer Windows for day-to-day work.

China: Ubuntu Kylin. China's sovereign Linux effort is perhaps the most ambitious, driven by a national strategy to reduce dependence on American technology. Ubuntu Kylin is backed by significant state resources and integrated into government procurement requirements.

Germany: Munich's LiMux: The Cautionary Tale. Munich's LiMux project is the case study that every sovereign OS advocate must reckon with honestly. In 2003, the city of Munich migrated 15,000 government workstations to a custom Linux distribution. The migration was technically successful. But over the following decade, the project faced relentless opposition: user complaints about incompatibility with Microsoft-formatted documents, political lobbying by Microsoft (which relocated its German headquarters to Munich), and negative media framing. In 2017, the Munich city council voted to migrate back to Windows, costing €90 million.

The Munich lesson is not that sovereign Linux is impossible. It is that the technical migration is the easy part. The hard parts are change management, political sustainability, and interoperability with the Microsoft-dominated ecosystem.

The Change Management Problem

If NepalOS is deployed in government offices, hundreds of thousands of civil servants will need to learn a new operating system. The keyboard shortcuts are different. The file manager looks different. The way you save a document, connect to a printer, or access a network share are all different.

This sounds trivial. It is not. Studies of enterprise software migrations consistently show that user resistance and productivity loss during transition periods are the primary causes of project failure, not technical deficiencies.

A realistic migration plan would need to include:

• Pilot deployments in a limited number of offices (perhaps public schools and municipal offices) before any broad rollout
• Parallel operation periods where both Windows and NepalOS are available, allowing users to transition gradually
• Dedicated training programs with in-person instruction, not just online tutorials
• A professional help desk staffed by Nepali engineers who can resolve problems in real time, in Nepali
• Document format compatibility: LibreOffice must reliably open, edit, and save Microsoft Office formats, because government offices exchange documents with external entities that use Microsoft products

The FOSS Nepal Community has the knowledge and passion to support this effort, but they are volunteers, not a professional support organization. A successful NepalOS deployment requires institutionalizing support by creating a professional entity, possibly under the National AI Centre, with full-time staff, defined service levels, and a budget.

The Consumer Playbook: Self-Host, Brand, and Maintain

NepalOS is the most visible piece of the software sovereignty strategy for the government, but there is an equally important strategy for the public: providing domestic alternatives to foreign consumer applications.

A common misconception in digital sovereignty is the belief that a country must build everything from scratch. The idea of coding a "Nepali WhatsApp" or a "Nepali Instagram" from the ground up is a trap, requiring massive capital and years of development to match the features of global competitors.

True software sovereignty does not mean reinventing the wheel. It means adopting the "Self-Host, Brand, and Maintain" playbook.

Instead of writing new software, Nepali developers take existing, world-class open-source platforms, host them on domestic servers, brand them for the local market, and maintain them. You start by simply hosting the software. As the local engineering team scales the infrastructure and fixes bugs, they become experts in the codebase. Eventually, they transition from merely hosting to actively developing and contributing new features upstream.

Consider how this applies across different software categories:

Productivity (The Google Workspace Alternative) Instead of paying Microsoft 365 or Google Workspace licensing fees, a Nepali company can self-host Nextcloud integrated with LibreOffice (or Collabora Online). This provides a full office suite in the browser, identical to Google Docs, but the data physically resides on Nepali servers. The government or private sector avoids legal fees, and citizen data remains domestic.

Social Media (The Instagram Alternative) Platforms like Pixelfed offer an open-source, federated alternative to Instagram based on the ActivityPub protocol. By self-hosting a Pixelfed instance, a Nepali tech startup could offer a photo-sharing platform where the algorithm isn't controlled by Meta, the data isn't mined for foreign advertising, and moderation policies reflect Nepali cultural contexts.

Messaging (The WhatsApp Alternative) Building a secure messenger is cryptographically difficult. Instead, Nepali developers can leverage platforms like Matrix (using the Element client) or fork the Signal codebase. Signal's client and server are both open-source, making it possible to run a fully domestic, end-to-end encrypted messaging service. By contrast, Telegram is a cautionary tale: while its client app is open-source, the server software is proprietary and closed. A country cannot truly self-host Telegram, meaning they remain dependent on a foreign corporation's infrastructure. To achieve sovereignty, the backend must be as open as the frontend.

We can look to Europe for models of how to organize this broader stack. The CollabNext initiative is a federated European stack where different providers own specific layers (infrastructure, security, collaboration, and communication) to avoid single-vendor lock-in.

Similarly, Nepal can adopt the Danish OS2 municipal model, where municipalities collaborate to fund and share open-source solutions. Instead of each of Nepal's seven provinces purchasing separate proprietary software, a provincial association could jointly fund the localized hosting and maintenance of an open-source tool, sharing the cost while keeping the software legally sovereign.

This approach delivers three massive benefits:

1. Zero Licensing Fees: Capital stays inside the country rather than flowing to Silicon Valley.
2. Data Sovereignty: Citizen data never leaves Nepal's borders.
3. Capacity Building: By maintaining these massive, complex systems locally, Nepali developers become world-class infrastructure experts.

But transitioning the public and the state to this open-source ecosystem requires answering a critical economic question: If the software is free, who maintains it, and how do we fund the transition sustainably? That question is answered in the next chapter.

Key Takeaways

• Nepal's estimated $50M–150M annual proprietary software spend is foreign currency flowing to Silicon Valley; redirecting even half of it to domestic OSS services would create thousands of Nepali jobs and seed a self-sustaining tech industry.
• The complete open-source stack (NepalOS, LibreOffice, Nextcloud, ERPNext, Element, Jitsi, Matomo, Keycloak, PostgreSQL) has no missing layers; every component is in production use globally and can be localized for Nepal.
• The Munich LiMux failure teaches that change management and political sustainability matter more than technical excellence: pilot deployments, training, parallel operation, and local help desk support are essential.
• The OS should be designed with quantum-resistant cryptography from the start, ensuring it remains secure through the coming quantum computing transition.
• The consumer playbook of "Self-Host, Brand, and Maintain" allows Nepal to deploy world-class platforms like Nextcloud, Pixelfed, and Signal (forked) without coding them from scratch.