The Government Wants Open Source, But Its Own Procurement Rules Get in the Way

India's Policy on Adoption of Open Source Software for Government of India, notified by the Department of Electronics and Information Technology in 2015, states plainly that government organisations should prefer open source software over proprietary alternatives when evaluating options for new IT systems, citing cost savings, vendor independence, security transparency and the broader public value of software that citizens and other government bodies can inspect, modify and reuse. Almost a decade later, the policy remains formally in force, occasionally cited in official communications, and only partially reflected in how government departments actually procure software.

Where open source in Indian governance has genuinely worked

It would be wrong to characterise India's open source engagement in government as purely aspirational, because several of the country's most consequential digital public infrastructure projects have embraced open, shareable code models with real success. CoWIN, the vaccination registration and certification platform built during the COVID-19 pandemic, was explicitly designed with an open API architecture and its underlying approach was offered to other countries as a digital public good, reflecting a philosophy distinct from proprietary, closed vendor software. DIKSHA, the national digital learning platform used by states across the school education system, is built on open source components and has been adopted and customised by multiple state governments independently, precisely the kind of reuse and adaptation that open architecture is meant to enable. The broader India Stack ecosystem, including Aadhaar's authentication APIs and the Unified Payments Interface, was built on open standards and API-first principles even where specific underlying implementations are not fully open source, allowing an ecosystem of banks, fintech companies and government departments to build on shared infrastructure rather than each building bespoke, incompatible systems.

These successes share a common origin story worth noting: they emerged substantially from mission-mode units and dedicated technical teams, often staffed by technologists brought in on relatively short assignments with strong political backing and some insulation from standard government procurement processes, rather than from routine departmental IT procurement following the standard General Financial Rules tendering process.

Where routine procurement defeats the policy's intent

Away from these flagship mission-mode projects, the more mundane, larger volume of everyday government software procurement, state government department portals, municipal corporation management systems, university administrative software, tends to follow a different pattern that the 2015 policy has done little to change. Government tendering processes, built around the General Financial Rules framework designed originally for procuring physical goods and construction services, evaluate software vendors substantially on the lowest technically qualifying bid and on the vendor's prior experience delivering similarly scoped, packaged proprietary solutions, criteria that structurally disadvantage open source-based bids from smaller companies or the informal open source developer ecosystem, which typically cannot point to the kind of large completed contract portfolio that public tenders often require as a qualifying criterion.

Large established technology vendors selling proprietary, licensed enterprise software have refined their government sales and tendering approach over decades, often shaping technical specifications in tender documents, sometimes through legitimate pre-tender consultation processes, in ways that favour features and architectures specific to their own products, a pattern documented in procurement critiques across many countries and not unique to India, but one that consistently disadvantages open source alternatives that may achieve the same functional outcome through different technical means not explicitly anticipated in the tender specification.

The total cost of ownership argument gets lost

Proponents of open source adoption in government argue, with reasonable evidentiary support, that while proprietary software licensing costs may sometimes appear lower or comparable at initial procurement, the long-term total cost of ownership, including recurring licence renewal fees, vendor lock-in that raises the cost of ever switching systems, and the absence of source code access that would allow government technical teams to maintain, audit or extend software independently once the original vendor contract ends, frequently favours open source alternatives over a multi-year horizon. Government procurement processes, however, are structurally oriented toward evaluating and approving costs within a single budget cycle or a specific contract term, and are poorly equipped institutionally to weigh the multi-year total cost of ownership calculus that would make the open source case more persuasive to a procurement officer under pressure to close a tender within an annual budget deadline.

Security transparency: the argument that cuts both ways

A genuinely contested aspect of the open source debate concerns security. Advocates argue that open source code, because it can be inspected by anyone, tends over time toward more scrutinised, transparently patched security than proprietary code whose vulnerabilities are known only to the vendor until disclosed, an argument with real historical support from major open source projects that have undergone extensive security audits by independent researchers globally. Sceptics within government security establishments counter that open source software is only as secure as the community maintaining it, and that critical government systems, particularly those touching sensitive citizen data or national security functions, benefit from the accountability of a single contracted vendor who can be held liable and mandated to respond to a disclosed vulnerability within a specific contractual timeline, an accountability structure less clearly defined when a government department is running community-maintained open source code without a formal support contract in place. Both positions have genuine merit, and the right answer likely depends on the specific system and its risk profile rather than a blanket preference either way, an argument for the current policy's stated general preference for open source while allowing case-by-case exceptions, rather than for abandoning the preference altogether.

What would close the gap between policy and practice

Several concrete procurement reforms could meaningfully narrow the distance between India's stated open source preference and its actual practice. Reforming tender qualification criteria to accept demonstrated open source contribution history and community reputation as valid substitutes for traditional large-contract portfolio requirements would open bidding to a wider and often more cost-effective set of vendors and developer collectives. Establishing dedicated, adequately staffed in-house government technology teams, following the CoWIN and DIKSHA model, for a wider range of routine departmental software needs rather than defaulting to external tendering for every project, would reduce dependence on the procurement process's structural biases altogether for at least a larger share of government software needs. And mandating total cost of ownership analysis spanning several budget years as a required element of significant software procurement evaluations, rather than allowing single-year licensing cost comparisons to dominate, would surface the long-run economic case for open source alternatives that current procurement timelines systematically obscure.

A policy that needs institutional teeth, not just intent

India's open source policy has never lacked good intentions or even good evidence, in its own flagship digital public infrastructure projects, for what is achievable. What it has lacked is the institutional reform of the underlying procurement machinery that determines outcomes for the much larger volume of routine government software purchases outside a handful of high-profile mission-mode exceptions. A decade is long enough to have learned this lesson, and the next phase of India's digital governance ambitions would benefit far more from fixing the tendering rulebook than from issuing another restatement of a preference the current rulebook already quietly overrides.