United Nations Open Source Week 2026

A couple of weeks ago, I got the opportunity to speak and attend the UN Open Source Week in New York.

It was intriguing to listen in on the perspectives of different countries' approaches to AI adoption, especially their active investment in open source. Across the different days, we spent time discussing policies, the importance of open source, infrastructure, and what to do when your software vendor lets you down.

My peak days were the maintain-a-thon day, hosted by Sovereign Tech Agency, and the community-led event day, where I was speaking at IBM on open-source stewardship in the age of AI.

During the maintain-a-thon day, I participated in group discussions about how AI is opening the door to new open-source contributors and how we are all dealing with the influx of new PRs. We talked about charting pathways for folks who may have had a falling-out, are under suspension, or are on a ban due to spamming. This includes pairing the user with someone who can provide help if they still want to be involved in the project.

Some new things that we encouraged each other to have in the open source projects we are involved with is:

• Have labels or a maintainer file about who is in charge to make it easier for new contributors
• Credit all the contributors including testers and users who helped in the issue

Some discussions on security which included a TIL(Today I Learned) for me was on testing your dependencies. The purpose of this was so thay you have the most secure patches. You can check out the hyrums tests here for more. The idea of the tests is to mirror how your code uses each dependency.

My notes from the security discussion were:

• The time for taking advantage of obscurity in security is dead and gone
• Incident reports are now assumed to be public. Assume the 90-day disclosure clock is already expiring. Fix the incidents immediately.
• We need stakeholder engagement and cross-team buy-in throughout the process
• Classify security reports by severity to prioritise fixing high-risk vulnerabilities first
• Maintain full visibility over reporting pathways to ensure security disclosures reach the right decision-makers without delay.
• Set up clear, highly visible reporting channels across your pages so anyone can flag security incidents immediately.
• In order to thrive in the ecosystem, you need to understand both core engineering and prompt engineering.

My favourite bit about the community day was giving my talk. The talk was titled "Open Source Stewardship in the Age of AI." This is the written version of the talk:

Open Source Software(OSS) is infrastructure that is currently under a lot of strain. In 2024, Harvard Business School conducted a study finding that 96% of commercial software relies on open source, with the total value of that code estimated at $8.8 trillion. That is $8.8 trillion made off the back of a small group of humans doing unpaid work.

The sustainability crisis of OSS predates AI. The OSS ecosystem runs on a structurally broken model in which a handful of volunteers maintain critical infrastructure used by billions for free. Most packages have one or two active maintainers, but more often than not, it's just a single person, with no backup, no succession plan, and no compensation plan, too. Many of the packages powering our production stack are one maintainer's life event away from going dark. The Maintainer problem is not new.

Jannis Leidel founder of Jazzband, said in 2017 that a sustainable solution doesn’t exist without serious financial support, but nothing changed.

The XZ Utils backdoor incident in 2024 was when a hacker spent two years building trust, tricking a single, exhausted volunteer into handing over the keys to software that powers most of the internet, nearly allowing them to compromise millions of servers worldwide.

GitHub launched Copilot in 2021, trained on code that maintainers and contributors wrote for free, without compensating them.

OSS was far from stable before AI. It was a system running on goodwill, good faith, inertia, and the fact that nothing catastrophic had happened yet. AI did not create the fragility. It inherited the said instability and scaled it up.

The introduction of Auto-generated code also introduced the Volume Problem, where maintainers are now bombarded with much more code to review in the same number of hours and much more noise. However, there was a small win: the barrier to contributing to OSS was lowered.

"Auto-generated issues and pull requests increase volume without always increasing the quality of the project." — GitHub Blog, 2026

Signals in OSS are clean code, fast turnaround, and the ability to handle complexity, which means someone has invested time. But now AI can fake all of that in seconds. This led to the participation paradox where in a project:

• More contributors did not equate to more progress
• Higher volume PRs produced more noise, not higher signal.
• Fast code generation didn't accelerate decision-making.

Naturally, there was a split in how the ecosystem viewed open source in the age of AI. On one side, some developers believed that AI, as a vehicle rather than a co-pilot, breaks the social contract of open source. On the other hand, some developers believed that the cat was out of the bag and we should focus on building better infrastructure for it.

Both of these thoughts point to the same root cause from different angles. The problem is not necessarily AI. The problem is:

• Insufficient human understanding behind contributions
• Maintainers absorbing costs they did not sign up for
• No tooling or norms designed for this scale

Both argue for the intentional design of contribution workflows.

Advantages of AI for OSS:

• Lowers the barrier to entry, making it easier for new developers to contribute
• Reduces repetitive work by helping generate documentation and boilerplate code
• Expands participation by enabling more developers from around the world to contribute
• Helps identify duplicate issues, detect regressions, and organise incoming reports
• Assists maintainers by filtering low-value pull requests before they reach human reviewers

Disadvantages of AI for OSS:

• A lot more PRs for maintainers to review using the same review bandwidth
• Code quality no longer implies understanding
• You can't tell if you're talking to a person or a wrapper
• Generated code can introduce subtle bugs or security weaknesses at scale
• Maintainers were already at capacity; this adds cognitive strain, not help
• Accountability gaps. When an AI-generated PR causes a bug, who owns it?

Maintainers approaching AI as infrastructure support and not a productivity shortcut are seeing real gains.

What's working:

• AI is triaging issues, detecting duplicates, and handling routine labelling, which is freeing the maintainers to focus on decisions that need human decision-making.
• Adding the AGENTS.md and HOWTOAI.md files lets maintainers set rules for how AI tools and agents behave in the repository
• Tools like CodeRabbit and Sweep can analyse whole repositories (not just PR diffs), learn from maintainer feedback over time, and flag faults before they reach a human reviewer.
• AI helps newcomers understand unfamiliar codebases and draft first patches sooner.
• Tackling work that would otherwise not happen, especially when cost and time are a factor in implementing the feature

Maintainers are now regarded as stewards of common digital infrastructure, which means the responsibilities now include:

• Setting contribution norms that hold in an AI-augmented world
• Designing workflow systems, not just reviewing individual PRs
• Protecting the trust model of the project
• Making sustainability decisions that affect downstream users

What we can do:

• As contributors:

  • We need to understand the code before you submit it, regardless of how it was generated
  • Read the contribution guidelines. AI is a tool in your hands, not a shortcut around understanding

• As maintainers:

  • We should haveHOWTOAI.md and Agents.MD files before we're overwhelmed
  • Invest in CI and automated quality checks to catch common issues early
  • Be explicit about our project's stance on AI contributions

• As organisations:

  • Fund the maintainers your products depend on
  • Contribute engineering time, not just tokens
  • Treat open source dependencies as infrastructure budget, not a free tier

Here is the link to the pictorial presentation

At the end of the day, AI is just a tool, and tools are defined by how we choose to use them. If we want open source to stay healthy and sustainable, we have to have clear boundaries, be smart on how to adopt, and have a common commitment to supporting contributors and maintainers.