Open-source projects have mature systems for code contributions, but not for every kind of contribution.
The gap we work on
A maintainer merging a code change has decades of infrastructure behind the decision: a test suite, a linter, a diff a reviewer can read, an owner who is accountable for the file. A maintainer merging a translation has almost none of it. Neither does one merging an accessibility fix, or — increasingly — one deciding what to do with a pull request written with an AI assistant.
The result is predictable and repeats across projects. Locale files go unscanned and unreviewed because no reviewer reads the language. Accessibility pull requests are evaluated on whether they look correct rather than whether they work with a screen reader. AI-contribution rules are invented from scratch by each project, in incompatible prose, in a file no tool can read.
These are not culture problems. They are missing infrastructure, and missing infrastructure is buildable. Our method is deliberately narrow:
- Study real projects and primary sources — not surveys, not opinion.
- Name the recurring infrastructure gap precisely enough to test.
- Score or catalogue what communities have already invented on their own.
- Ship the smallest reference artifact the evidence supports — a linter, a rubric, a schema.
- Invite critique from maintainers, practitioners, and foundations, in public.
Workstreams
Four domains, one method. Every artifact below is public, Apache-2.0 or CC-licensed, and usable today without talking to us.
-
Shipped · in use
Language inclusion
Open source ships English-first, and the locale files that follow are the least-reviewed text in the repository.
Field work on how localization contributions are actually reviewed upstream, and what that under-review lets through. The tooling output is a CI scanner for four defect classes that survive translation — bidirectional-text overrides, injected markup, format-string drift, and broken interpolation — so a maintainer who does not read the language can still merge safely.
Open the repo for oss-language-inclusion (opens in a new tab) pip install i18n-security-lint PyPI (opens in a new tab) -
Active research
Accessibility contribution review
We scored seven real accessibility pull requests against a 12-point rubric. None reached the mature band, and the most heavily reviewed one tied for the lowest score.
A meta-review of how accessibility work is reviewed in practice, plus the reusable pieces that came out of it: an ACCESSIBILITY.md template, issue and pull-request templates, and a review rubric that lets a non-specialist reviewer ask the right questions. Contributor-facing tasks are labelled by whether they need lived experience with assistive technology.
-
Draft standard
AI contribution policy
Nine projects. Five incompatible postures. One proposed machine-readable shape.
A verified catalogue of what projects including curl, Ghostty, LLVM, and tldraw have actually written about AI-assisted contribution — sourced from the policies themselves, not reporting about them — and a draft ai-contribution-policy.yml so the rules become something CI and contributor tooling can read. The design position is verification over detection, and disclosure over bans: detection does not work, and bans push disclosure underground.
-
Shipped · in use
Machine-operable documentation
The examples in your README are the most-copied, least-tested code you ship — now to AI agents as much as to people.
Documentation is read by agents at a scale humans never matched, and a stale example is now a failure mode rather than an annoyance. readme-ci extracts the code examples from Markdown, classifies which are safely runnable, and executes those in a locked-down container with no network, so “our examples still work” becomes a CI check instead of a hope. Developed under the Machine-Operable Open Source programme.
Evidence and writing
The research is published where practitioners and reviewers can argue with it, and the underlying data stays in the public repositories above.
-
Communications of the ACM · May 2026
Why the localization gap in open source is an infrastructure problem rather than a translation problem.
-
DevOps.com · June 2026
A field report tracing five real localization contributions through review, and what stalled each one.
-
Essay · August 2026
On accessibility overlays as a supply-chain and trust question, not only a usability one.
Roadmap
What is committed, what is next, and what needs funding to happen at all. We publish this so it can be held against us.
-
Now
Adoption over new surface area
Drive real installs of the two shipped tools rather than starting a fifth workstream. Concretely: i18n-security-lint 0.2.0 with additional checks and locale formats drawn from contributor issues, and demonstrated container execution for readme-ci against live projects.
-
Next
Accessibility signals, validated
A validator for a11y-signals.yml so the accessibility metadata a project declares can be checked mechanically, and a second cohort of scored pull requests to test whether the maintainer-versus-contributor pattern in the first study holds elsewhere.
-
Next
AI contribution policy v0.2
Expand the verified catalogue, then take the schema to projects and foundations for critique. Success is another project adopting the format — not us publishing a standard nobody implements.
-
Needs funding
Sustained maintenance and lived-experience review
The work above is currently unfunded and part-time. Funding buys three things volunteers cannot reliably supply: continuous maintenance of shipped tools, paid review by people who use assistive technology daily, and Indic-language reviewers for locale work at more than a token scale.
Funding and use of funds
The initiative is independent and currently self-funded. We publish what money would be used for before asking anyone for it.
-
Maintenance of shipped tools
Keeping i18n-security-lint and readme-ci alive as dependencies change: issue triage, releases, security response, and support for the projects that adopt them.
-
Paid lived-experience review
Accessibility findings reviewed by people who use screen readers and other assistive technology daily. This is expert labour and we do not think it should be donated.
-
Indic-language review capacity
Reviewers for Hindi and other Indic locales, so localization contributions are checked by native speakers rather than accepted on trust.
-
Research and publication
Field studies of real repositories, the corpora behind them, and open publication of the results and the data.
-
Infrastructure
CI and sandboxed-execution compute for the tooling, plus the ordinary costs of running public repositories and this site.
Funders and OSPOs: the detailed budget, milestones, and reporting cadence are available on request — including the specific proposals already prepared for accessibility contribution review and the machine-operable programme. We would rather send you the numbers with context than post a figure without one.
Contribute
Most of what this work needs is not code. It is people who can read a language, use a screen reader, or tell us that a rubric asks the wrong question.
Start with an open issue
The accessibility repository has issues split into two tiers: tier-a tasks are claimable cold with no prior accessibility experience, and tier-b tasks need hands-on experience with assistive technology. Start at tier A.
Review, don't code
Findings marked needs-lived-experience-review are waiting on someone who uses assistive technology, not someone who can write a patch. The same applies to Hindi and other Indic locale review.
Use the tools and tell us they broke
Running the linter against your own project and reporting what it got wrong is a genuine contribution. False positives are bugs and we treat them that way.
pip install i18n-security-lint
Register your interest
Tell us what you can help with and we will point you at something real. We will not add you to a mailing list.
About and contact
The OSS Infrastructure Initiative is an independent research programme based in Bengaluru, India, run by Sanjay C. It is not a foundation, a company, or a consultancy. The public face of the work is the artifact and the named researcher behind it.
We welcome conversations with maintainers, OSPOs, foundations, researchers, and journalists working on these gaps — including disagreement with our findings.