Chapter 7: The Economics of Open Source

The Charity Misconception

When governments consider adopting open-source software, a predictable objection arises: If the software is free, who maintains it? Are we entrusting national infrastructure to unpaid volunteers coding in their basements?

This misconception, that open-source is a form of charity or an academic hobby, is decades out of date. Today, open-source is a commercial juggernaut, representing tens of billions of dollars in global venture funding. It is the foundation of the modern internet, running the majority of the world's web servers, smartphones, and cloud infrastructure. But more importantly for Nepal's strategy, it is the foundation of thousands of highly profitable, sustainable businesses.

For Nepal to succeed with NepalOS and its surrounding software ecosystem, the government must recognize that adopting open-source does not mean relying on free labor. It means shifting capital from foreign licensing fees to domestic service contracts. The software is public property, but its maintenance, hosting, custom development, and support are professional services that must be paid for.

The Revenue Engines

To understand how Nepali tech companies can build profitable, sustainable businesses around sovereign software, we can look to the Commercial Open Source Software (COSS) industry. A recent empirical study by Utrecht University examined ten commercial open-source companies across five countries. The study's core finding was unambiguous: building a business around open-source software is not fundamentally harder than building one around proprietary software. The revenue logic simply shifts. Instead of selling the code itself, companies sell complementary services, convenience, and guarantees.

Four distinct business models have proven commercially viable globally, and all four are directly applicable to Nepal's context:

1. Support and SLA Contracts

This is the classic model pioneered by Red Hat, which became a multi-billion-dollar enterprise by giving away its Linux distribution for free and charging for guaranteed technical support.

In this model, the software is 100 percent open-source and free, but the company charges recurring subscription fees for Service Level Agreements (SLAs). An SLA guarantees that if a government office's server crashes, a domestic engineering team will respond within a defined timeframe (e.g., one hour). It guarantees that critical security patches will be applied within 24 hours of release.

For Nepal, a professional support entity (possibly under the National AI Centre, or private consortia) can offer tiered SLA contracts to government agencies. The government pays the same amount it would have paid Microsoft or Oracle for support, but the capital stays in Nepal, paying Nepali salaries.

2. SaaS and Managed Hosting

While software may be free to download and self-host, managing servers, installing updates, managing backups, and ensuring uptime is difficult and expensive for most organizations.

In this model, a domestic cloud provider offers the convenience of hosted Nextcloud, ERPNext, or Matomo. The software runs in the cloud (ideally in the high-altitude green data centers described in Chapter 4) and is powered by Nepali hydropower. The government pays for the convenience and reliability of Software-as-a-Service (SaaS). Crucially, because the underlying software is open-source, there is no vendor lock-in. If the domestic hosting provider raises prices unfairly, the government can take its data and the open-source software to a different provider.

This model extends to the consumer playbook described in the previous chapter. A local startup hosting Nextcloud and LibreOffice for local businesses provides a recurring SaaS revenue stream, replacing the licensing fees those businesses previously paid to Microsoft or Google.

3. The Open Core Model

This is currently the most proven commercial approach for scaling open-source companies, used by globally successful platforms like GitLab and Bitwarden.

The core software is open-source and free to self-host. However, advanced "enterprise" features (such as single sign-on integration, advanced auditing logs, compliance modules, or high-availability clustering) are proprietary and require a paid license.

For Nepal, the Open Core model offers a path to build software that serves both small local businesses (who use the free version) and large government ministries or international clients (who pay for the enterprise features). The revenue from enterprise licenses funds ongoing development that benefits all users.

4. Custom Development and Integration

Government systems rarely fit off-the-shelf software perfectly. There are legacy databases to integrate, specific workflows to automate, and local regulations to comply with.

Nepali tech companies can bid on government contracts to develop Nepal-specific customizations, such as a Devanagari NLP module for LibreOffice, an integration between ERPNext and Nepal's tax system, or a custom module for land administration. The custom code becomes part of the open-source commons, benefiting all provinces and future deployments, while the development work creates high-skill local employment.

---

The Domestic Procurement Engine: A Flywheel for Growth

The $90 million digital transformation fund from the World Bank and ADB (discussed in Chapter 8) represents a massive procurement opportunity.

Historically, such funds are spent purchasing proprietary licenses from foreign tech giants and paying foreign consulting firms to implement them. The capital enters Nepal and immediately leaves. The economics of open source allow Nepal to keep that capital within its borders.

When a government ministry decides to deploy ERPNext for its accounting, or Nextcloud for its document storage, it should not expect its own civil servants to install and maintain it. Instead, it should issue a procurement contract to a domestic tech company to manage the deployment, host the data, and provide 24/7 support.

This creates an economic flywheel:

   ┌────────────────────────────────────────────────────────┐
   │                                                        │
   ▼                                                        │
┌────────────────────────────────────────────────────────┐  │
│ Government redirects M365/Oracle licensing fees       │  │
└───────────────────────────┬────────────────────────────┘  │
                            │                               │
                            ▼                               │
┌────────────────────────────────────────────────────────┐  │
│ Procurement of domestic open-source service contracts  │  │
└───────────────────────────┬────────────────────────────┘  │
                            │                               │
                            ▼                               │
┌────────────────────────────────────────────────────────┐  │
│ Local tech companies hire and train Nepali engineers   │  │
└───────────────────────────┬────────────────────────────┘  │
                            │                               │
                            ▼                               │
┌────────────────────────────────────────────────────────┐  │
│ Engineers contribute code back to NepalOS/open stack   │  │
└───────────────────────────┬────────────────────────────┘  │
                            │                               │
                            ▼                               │
┌────────────────────────────────────────────────────────┐  │
│ Software becomes more secure, localized, and resilient │  │
└───────────────────────────┬────────────────────────────┘  │
                            │                               │
                            └───────────────────────────────┘

The outcome is radically different from purchasing foreign licenses:

1. The capital stays in Nepal, paying the salaries of Nepali engineers rather than flowing to Silicon Valley. Utrecht University research confirms that 80 percent of COSS company costs are personnel. Every rupee spent on domestic open-source services pays Nepali salaries.
2. The software remains sovereign. The government owns its data and can inspect the code, eliminating foreign dependencies.
3. The ecosystem grows. The domestic tech company, enriched by the government contract, now has the resources to contribute code back to the open-source project, improving the software for everyone and attracting private-sector or international clients.

Mitigating Provider Failure

A legitimate concern with any government digital platform is: what happens if the vendor goes bankrupt or disappears?

With proprietary software, this is catastrophic. The source code is locked, the format is proprietary, and migration is prohibitively expensive. With open-source, the code is always available. If a Nepali hosting provider fails, another can take over the same stack. The data is in open formats. The transition is straightforward. Open-source eliminates the single-vendor lock-in risk that makes proprietary dependency dangerous.

---

Procurement Reform: Mandating Open Source in Government

NepalOS and its surrounding stack will not succeed through enthusiasm alone; they require institutional procurement reform. This entails changing how the government purchases technology to make open-source software the default, and proprietary licenses the exception requiring strict justification.

The following reforms should accompany the NepalOS deployment:

1. Open-source-first policy. All new government IT procurement should require a default evaluation of open-source alternatives before proprietary solutions are considered. This is not a mandate to always choose open-source, as there may be cases where proprietary solutions genuinely offer superior capability, but it ensures that sovereign options are evaluated first. The Danish government's 2025 political agreement established this principle: open-source is the default in public IT, with proprietary alternatives requiring documented justification.
2. Sunset clauses on existing licenses. Existing Microsoft and proprietary license contracts should include no-renewal clauses. As contracts expire, they are not renewed. Instead, the workstations migrate to NepalOS with domestic support contracts. This avoids the shock of immediate mass migration while creating a predictable, declining proprietary footprint.
3. Vendor neutrality requirements. Procurement specifications should not name specific proprietary products. Terms like "Microsoft-compatible" or "Excel-compatible" should be replaced with standards-based requirements: "must support ODF (Open Document Format) and import/export Microsoft Office formats." This prevents vendors from writing specifications that exclude open-source alternatives.
4. Total cost of ownership (TCO) evaluation. Procurement evaluations should consider 5-year and 10-year total cost of ownership, not just the initial purchase price. Proprietary licenses may appear cheaper upfront but compound over time with renewal fees, version upgrades, and vendor lock-in costs. Open-source has higher initial migration costs but dramatically lower recurring costs.
5. Budget reallocation. Funds saved from proprietary license elimination should be earmarked for three priorities: (1) NepalOS development and maintenance, (2) domestic OSS support company contracts, and (3) training programs for government IT staff. This prevents savings from being absorbed into general budgets and ensures they fund the transition.

---

Measuring Success: KPIs for Software Sovereignty

What cannot be measured cannot be managed. The software sovereignty initiative should track the following key performance indicators:

These metrics should be reported annually to Parliament and published publicly. Transparency builds accountability, and accountability sustains political will.

---

Key Takeaways

• Open-source is not charity: it is a commercial model supported by proven B2B revenue mechanisms (SLA support, SaaS, open core, and custom integration).
• The Utrecht University research confirms: 80% of open-source company costs are personnel. Shifting to domestic OSS keeps capital in Nepal, paying Nepali salaries.
• The $90 million World Bank/ADB digital transformation fund is a procurement opportunity: if spent on domestic open-source service contracts instead of foreign license fees, the capital stays in Nepal and builds the local ecosystem.
• Open-source mitigates provider failure: if a local vendor fails, another can take over the same stack because the source code is public and data is stored in open formats.
• Procurement reform is the political lever: open-source-first policies, sunset clauses on proprietary licenses, vendor neutrality requirements, and TCO-based evaluations ensure systematic adoption.
• The software sovereignty initiative should be managed against measurable KPIs reported annually to Parliament to sustain political will across election cycles.