GitHub for Government Work
The multi-year, single-vendor RFP is the root cause. Treat the core platform as an open commons instead: small priced tasks, paid per merged pull request, governed hard.
When I ran my agency, the two mistakes that hurt the most were these. I said yes to scopes I could not see the bottom of. And when I expanded into frontend dev, I could not reliably judge the quality of work I had not built myself, so by the time the problems surfaced we were already deep in delivery and the trust was gone.
That is a small business making a survivable mistake. Now imagine making both of those mistakes on purpose, in writing, for five years, with crores on the line.
That is the government IT contract.
The last two posts were about the software: the meltdown, then the architecture that prevents it. But here is the catch I kept dancing around at the end of each one. That architecture cannot survive the way we buy software today.
The monolithic, multi-year, single-vendor RFP is the real root cause. It is slow to respond. It concentrates all the risk in one supplier. It draws from a tiny pool of firms big enough to bid in the first place. And it produces almost nothing anyone else can reuse.
Remember the vendor from the first post, the one that underbid TCS and got 66 days. That was not a freak event. That was the RFP model working exactly as designed: lowest bid, one throat to choke, a ship date fixed before anyone understood the problem.
Key Takeaways
- The multi-year, single-vendor RFP is the root cause: it concentrates every risk in one supplier and produces nothing reusable. Treat the core platform as an open commons instead — small, priced, security-governed tasks, paid per merged pull request.
- India has already shipped a smaller version. When it open-sourced Aarogya Setu in May 2020, it paid a ₹1 lakh bounty each — for code improvements as well as security bugs.
- Open contracting has a track record: Ukraine’s Prozorro saved roughly $1.9 billion in its first two years, and publishing EU tenders above a threshold raised bids per call by about 12%.
- The one thing you cannot skip is the steward. Fund it, staff it, give it authority — or do not open the commons at all. An ungoverned commons is worse than the monolith it replaces.
Stop pouring one giant contract. The same platform, rebuilt as a field of small, priced, security-governed tasks — each paid only when it merges.
The alternative is an open commons
So flip it. Treat the core government platform as an open commons, and treat the work as a stream of small, well-specified, security-governed tasks that any qualified developer or team can pick up and get paid for when their change is merged. Call it GitHub for government work.
Concretely:
- A public repository hub: the platform code, reference architectures, and standards, out in the open.
- An issue marketplace: work broken into classified, priced issues, each with a clear spec and acceptance criteria.
- Payment tied to merged, reviewed pull requests. Not to a signature on a contract, not to hours logged.
- Credential and environment checks before anyone touches anything sensitive.
- Governance dashboards, so the whole thing is measurable in public.
The work gets decomposed the way real engineering work already is. Task types: feature, hardening, bugfix, reference-data, documentation. Fixed award bands by size, XS through L. A risk classification on every task. And a “claim versus compete” rule: low-risk tasks you can just claim and do, high-risk ones go through a tighter, contested process.
Walk one task through it. Someone files an issue, and it gets a risk tier and a price. A qualified contributor claims it, or competes for it if it is high-risk, and does the work in a checked-out environment, not on a random laptop. They open a pull request. The pipeline runs the security gates. A maintainer reviews it, and only a merge releases the payment, to a verified account. No merge, no money. That single rule — pay on merge, not on signature — is what quietly fixes both mistakes I opened with. You cannot say yes to a scope no one can see the bottom of, because the scope is one reviewable change. And you cannot get paid for work nobody could judge, because the review is the payment gate.
None of this is exotic. It is innersource, the open-source collaboration model large companies already run internally, scaled up to a national commons.
Turn the bug bounty into a task bounty
If this sounds utopian, it is worth remembering that the Indian government has already shipped a smaller version of it. When it open-sourced the Aarogya Setu Android app on GitHub in May 2020, it launched a bug bounty: â‚ą1 lakh each, not just for finding security vulnerabilities, but for code improvements too. It even dropped the prohibition on reverse-engineering. The MyGov team hosted it; NIC ran the process, with every code suggestion going through pull-request review.
The leap is small in concept and large in effect. Apply that same bounty logic to all qualifying work, not just vulnerabilities. Features, hardening, documentation, anything with a clear spec and a clear acceptance bar. Wrap it in responsible-disclosure rules and you have an incentive system that pays for improvement instead of only punishing breaches.
But the thing that makes a bounty model safe is not the payout. It is the trust layer underneath it.
- Contributors get scored on what actually matters: the quality of merged work, their security record, how they behave in review, whether they follow disclosure rules, whether they are reliable.
- New contributors get brought in periodically, on purpose, so the system does not ossify into a closed guild of the same ten firms. Which is exactly the failure mode of the RFP world.
- Rule-breakers get deprioritized, suspended, or banned.
- And identity is the part you cannot fudge: the contributor’s identity, their tax identity, and their payout account all have to line up. MFA is mandatory. The highest-risk work happens inside managed development environments, not on someone’s laptop.
The reward on top is the easy part. What makes a bounty safe is the slab underneath it: identity that lines up, MFA, contributor scoring. Pay for the foundation, not the payout.
Governance is the load-bearing wall
Here is where I have to be blunt, because this is the part that turns a good idea into a disaster if you skip it. A commons without governance is not a commons. It is a bigger attack surface with a friendlier logo.
So the non-negotiable is a real steward. A body, NIC or a dedicated public-software board, that owns the core frameworks, the standards, the backlog triage, the CI/CD, the supply-chain controls, the incident response, and the architecture. Not a committee that blesses things after the fact. An owner. India has the institutional bones for this already: NeGD’s API Setu governance has a Schema Body, a Security Body, and a dispute-resolution group, and OpenForge exists specifically to run government open-source collaboration.
The supply chain has to be defended in the pipeline, not in a memo:
- Automated SAST and SCA scanning on every change.
- An SBOM generated for every build, and SLSA-style provenance on every artifact. SBOMs tell you what you built; provenance tells you who built it, where, and how.
- Signed artifacts, with keyless signing.
- An internal proxy registry of vetted dependencies, instead of pulling arbitrary versions straight off the public internet. Zerodha runs exactly this kind of Go module proxy, and they are a private company with a fraction of the attack surface.
- MFA on every developer and git account. No exceptions.
Defend the supply chain in the pipeline, not in a memo. Every dependency clears one gate — scanned, signed, proxied — before it reaches the vault.
And because it is 2026, an explicit AI-use policy:
- Disclose it when AI generated significant code, config, or docs.
- Never send secrets, production data, or non-public architecture to an external AI service.
- Human review, understanding, and refactoring before merge. You do not merge code you cannot explain.
- Licensing checks on generated content, and periodic audits of what people disclosed against what they actually shipped.
The principle under all of it is simple. The person who merges the code owns the code, no matter how it was produced.
The evidence is already in
This is not a thought experiment. Open contracting has a track record. After Ukraine put its public procurement online through Prozorro, it saved roughly $1.9 billion of public money in its first two years. And the average number of suppliers per procuring entity rose from 3.4 in 2012–2015 to 5.9 in 2017–2018. In the EU, simply publishing tenders above a threshold raised the number of bids per call by around 12%.
The mechanism is not magic. Transparency plus early, low-friction access to the work lets more players compete, and smaller ones too. More competition is cheaper and more resilient than one incumbent with a five-year lock.
Open the contracts, and more people show up to bid.
The pattern repeats elsewhere: across the EU, publishing tenders above the threshold raised bids per call by ~12%, and Prozorro saved Ukraine an estimated $1.9 billion in its first two years. Transparency lowers the barrier; competition does the rest.
Where this absolutely could go wrong
I would be selling you the same overconfidence I criticized in the first post if I pretended this has no failure modes. It has several.
Crowdsourcing has hard limits. Task bounties work for well-specified, bounded units of work with strong review attached. They do not replace architecture, they do not replace incident response, and they do not replace accountable ownership. Point a bounty board at “design our national identity system” and you will get chaos.
Open competition is not a free lunch either. The same EU study that found more bids per call also found the extra competition can come at the cost of weaker contract performance, when projects are complex or awarded purely on the lowest price. So you cannot just open the gates and walk away. You need real review and a hard acceptance bar — which is exactly what the merged-PR model puts back in. The pull request does not get paid until it passes; the cheapest bid does not win if the code does not merge.
A commons without governance is worse than a monolith. If the stewardship body cannot be funded, staffed, and given authority, do not open the commons at all. An ungoverned commons is just the meltdown again, distributed across more people.
Open the commons without a steward and you don't get a doorway, you get a breach. The meltdown again, just distributed across more people.
And this is a complement, not a replacement. Large integrated programs still need prime contractors who can be held to a delivery. What changes is how the core platform and its incremental work get built, not every government project everywhere. If anyone reads this as “abolish all RFPs,” they have misread it.
Stop buying software like it’s a bridge
We buy public software the way we build a bridge. One enormous contract, one winning firm, a ribbon-cutting, and then you walk away for five years and hope it holds.
Software is not a bridge. It is never finished, it is attacked continuously, and the moment you stop maintaining it, it begins to rot. That is the whole story of the last two posts.
So stop pouring the one big contract. Build a living commons instead: open by default, governed hard, paid out one merged improvement at a time.
Three posts, one machine. A leak that showed the stakes. A meltdown that showed the failure. An architecture that could prevent it. And a way of buying it that could keep it alive. Underneath all of them is the same mistake, made over and over: we concentrate enormous stakes into a single point — one exam, one vendor, one bucket, one contract — and then act surprised when the single point fails.
A bridge you build once. Software you keep. So buy it like you mean to keep it.
Frequently asked questions
What does “GitHub for government” actually mean? The core platform run as an open commons: public repositories, an issue marketplace of classified, priced tasks each carrying a spec and acceptance criteria, payment tied to merged and reviewed pull requests, and credential and environment checks before anyone touches anything sensitive — all of it measurable on public governance dashboards. It is innersource, the model large companies already run internally, scaled up to a national commons.
Has any government paid for code this way before? Yes, a smaller version of it. When India open-sourced Aarogya Setu in May 2020, the bug bounty paid â‚ą1 lakh each for code improvements, not just for vulnerabilities, with NIC running every suggestion through pull-request review. The task-bounty model just applies that same logic to all qualifying work with a clear spec and a clear acceptance bar.
Does open procurement actually save money or just add transparency? Both. Ukraine’s Prozorro saved roughly $1.9 billion in its first two years, while the average number of suppliers per procuring entity rose from 3.4 to 5.9. In the EU, publishing tenders above a threshold lifted bids per call by around 12%. Transparency is the lever; the savings and the extra competition are the output.
Doesn’t crowdsourcing government software create security risks? Only without governance. The safety is not the payout — it is the trust layer beneath it: contributor scoring, mandatory MFA, identity that lines up so the contributor, their tax identity, and their payout account are all the same person, SAST and SCA plus SBOMs and signed artifacts in the pipeline, and the highest-risk work confined to managed environments. A commons without a real steward is worse than a monolith.
Does this mean abolishing all government RFPs? No. It is a complement, not a replacement. Large integrated programs still need prime contractors who can be held to a delivery. What changes is how the core platform and its incremental work get built — not every project everywhere.
Sources and further reading - Aarogya Setu open-sourced with a ₹1 lakh bug bounty (MyGov) · Prozorro outcomes (OECD-OPSI) · The Impact of Open Data on Public Procurement (Duguay, Rauter & Samuels) · SLSA provenance framework · OpenForge (Government of India) · API Setu
What’s next?
This is part of a series on why India’s government software keeps falling over, and how I’d build it so it doesn’t:
- Stop Fixing India’s Exams — why you can’t patch a high-stakes exam into honesty, and the continuous competency profile that replaces it
- BTS of CBSE’s Infra Meltdown — why the result-day “cyberattack” was almost certainly just demand, and why the portal was built to fall over
- How I’d Actually Build Government Software That Doesn’t Fall Over — a federated core, HTML-first frontends, and storage you can’t make public
- GitHub for Government Work (you are here) — trading the multi-year, single-vendor RFP for an open commons paid per merged pull request
- Assume the Endpoint Is Hostile (coming soon) — locking down the lakhs of devices that reach the core, with a closed system on open foundations
One machine, five layers: the exam, the meltdown, the architecture, the procurement, and the endpoint.
