The UN Open Source Principles

UN Open Source Principle #1 reverses the burden of proof: teams justify why software should stay closed, not why it should be open. New York already lives by this rule for data — the Open Data Law (Local Law 11 of 2012) requires agencies to publish public data by default — and a handful of agencies already publish code on GitHub. What’s missing is a citywide default, rather than a matter of which agency happens to care.

UN Open Source Principle #2 is reciprocity: institutions that benefit from open source should upstream fixes, publish reusable tools, and engage the communities maintaining the software they depend on. Every large software company already works this way — not out of altruism, but influence: contributors steer projects toward their own needs. NYC could be doing the same.

UN Open Source Principle #3 treats security as a first-class requirement, not a patch applied after launch — and open code is inspectable code: community review surfaces vulnerabilities faster than a vendor’s word. New York already runs a citywide Vulnerability Disclosure Program for outside researchers. But for the vendor-purchased majority of city systems the code stays closed, so nobody outside the vendor can verify how well-built a system was to begin with.

UN Open Source Principle #4 calls for a broad, diverse contributor base — first-timers welcomed, documentation for non-experts, translation into the languages a community speaks. New York has the raw material: a famously diverse technical population, civic tech groups like BetaNYC, and nearly 2,800 applicants to PIT Crew’s first hiring round. What it lacks is a formal bridge between that community and the city’s own software.

UN Open Source Principle #5 calls for software built to work across platforms and contexts, so one government’s solution becomes every government’s head start. The contracts NYC signs decide whether its data stays portable, whether formats are documented, and whether a future administration can switch providers without rebuilding from scratch. As one of the largest municipal technology buyers in the country, the standards NYC writes into its solicitations ripple through the vendor market well beyond the five boroughs.

The strength of an open source project is largely derived from the comprehensiveness of its documentation; UN Open Source Principle #6 treats documentation as a deliverable. Documentation should be reviewed and maintained alongside the code so someone other than the original author can safely use, fix, or extend it. Vendor systems often ship with documentation that’s thin, outdated, or contractually restricted to the vendor’s own staff, so when a contract lapses or a key technologist moves on, institutional knowledge of how a system actually works can leave with them.

UN Open Source Principle #7 — Recognize, Incentivize, Support, and Empower — holds that institutions should formally back the people doing open source work, not leave it to individual initiative. The mechanism other governments use is an Open Source Programme Office: Munich runs one under a “public money, public code” mandate, and Barcelona paired its UN endorsement with a commitment to create one. New York’s Office of Technology & Innovation, which already coordinates technology citywide, is the natural host for one too.

UN Open Source Principle #8 calls for solutions that meet evolving needs over time — funded and maintained for the long run, not abandoned when a contract or donor cycle ends. The mechanism other governments use to fund this is a modest, dedicated pool of money. This can be modeled on Germany’s Sovereign Tech Agency, which has put over €24 million into keeping critical open source infrastructure maintained. The city already found $5.24 million in baselined funding for four PIT Crews, plus a fifth built with Rockefeller Foundation support.