Evidence Building
How to Present Open-Source Software Contributions as Original Contributions Evidence
Open-source software can satisfy the O-1A original contributions criterion, but only when the petition documents specific technical advances and independent adoption—not GitHub metrics. Here is what USCIS needs to see and how to present it persuasively.
The original contributions criterion and open-source work
The original contributions criterion under 8 C.F.R. § 214.2(o)(3)(ii)(A)(5) requires evidence of contributions to the field of major significance. For software engineers and researchers who produce open-source software as a primary output, this criterion offers a direct path if the evidence is assembled correctly—but also presents challenges that publication-based fields do not. The significance of open-source work is often distributed across contributors, expressed through metrics that may seem unfamiliar to adjudicators, and assessed through community dynamics that require explanation to be legible to USCIS. Providing that explanation—through expert declarations, adoption documentation, and a clear attribution narrative—is what distinguishes an approvable open-source contributions case from one that generates an RFE requesting clarification.
The foundational question is whether open-source contributions constitute contributions to the field in the sense the regulation intends. USCIS has adjudicated and approved petitions where open-source software formed the core original contributions evidence, and the AAO has addressed related arguments in non-precedent decisions. The practice is established—but the petition must frame open-source work in the context of research outcomes, field impact, and independent adoption, rather than pointing to a code repository. The measure of significance is not the number of commits or repository stars; it is the nature and extent of independent adoption and the expert assessment of what problem the work solved.
The specific challenge for open-source contributors is that significant contributions are often embedded in collaborative projects where attribution requires technical explanation. A petitioner who is the primary architect of a widely deployed machine learning library but shares commit history with dozens of contributors must construct a precise and accurate account of what they personally designed, what problem it solved, and why their contribution is not reducible to the collective effort. That attribution narrative is the starting point for the original contributions case and must be supported by contemporaneous documentation—design documents, technical blog posts, and release notes—rather than after-the-fact characterization.
What USCIS looks for in this context
USCIS evaluates original contributions claims by looking for specific, verifiable evidence that the petitioner's work has had a meaningful impact on the field—impact measured not by the petitioner's own assessment but by what independent sources confirm. For open-source contributions, the most persuasive evidence follows from the principle of independent adoption: if practitioners with no professional relationship to the petitioner have incorporated the petitioner's work into their own tools, products, or research, that adoption is evidence of significance. The measure of significance is the extent and quality of that independent adoption, not the absolute volume of usage metrics.
The regulation's major significance standard requires something beyond ordinary professional competence. In the open-source context, this means distinguishing between contributions that are well-executed implementations of known approaches and contributions that either solve a previously unsolved problem or improve substantially on prior approaches. The petition brief should identify, with specificity, the technical problem the petitioner's work addresses, what prior approaches existed, and why the petitioner's contribution represents a meaningful advance. This framing is familiar from patent prosecution and academic publication and translates well to USCIS review when presented by counsel with knowledge of the relevant technology.
Expert testimony about the significance of open-source contributions is not optional—it is essential. USCIS adjudicators are not software engineers, and they cannot independently assess whether a particular library or tool represents a major advance in the field. The expert declaration must translate the technical contribution into terms the adjudicator can evaluate: what the software does, what problem it solves, what practitioners used before, how widely it is now used, and why the expert considers it a significant contribution. A declaration that confirms the petitioner's technical skill without explaining the contribution's field impact provides essentially no support for the criterion.
Evidence that routinely satisfies this criterion
For open-source contributors, the most persuasive evidentiary package pairs technical documentation of the contribution with independent evidence of adoption and expert declarations addressing significance. On the adoption side, the petition should document specific real-world deployments: organizations that have integrated the petitioner's software into production infrastructure, academic papers that cite or build on the petitioner's library, or products with documented user bases that depend on the petitioner's work. This adoption evidence should come from third-party sources—press releases, academic publications, technical blog posts from organizations independent of the petitioner—rather than from the petitioner's own representations.
For open-source projects adopted by major foundations or enterprises, the adoption record may include governance documentation. An Apache Software Foundation project with a documented release history, an Eclipse Foundation project with active corporate contributors, or a library incorporated into the standard distribution of a major cloud platform provides categorical adoption evidence that is difficult to dismiss. The petition should document the governance structure of the project and the petitioner's role within it—whether as a founder, maintainer, technical steering committee member, or contributor with a specific leadership function that is distinguishable from general participation.
GitHub metrics—stars, forks, downloads—can provide context but should not serve as primary evidence of significance. Adjudicators have reviewed petitions that lead with repository star counts without explaining what those stars represent. A repository with 20,000 stars is meaningless to an adjudicator without context: are those stars from practitioners who use the library professionally, or from students who bookmarked it for reference? The petition should characterize the user community and document the practical deployment record. When usage statistics are included, they should be compared to benchmark figures for tools of similar scope and category within the same technology domain.
Evidence USCIS regularly discounts
The most common documentation approach that fails for open-source contributions is presenting GitHub profile statistics—total commits, repositories created, contribution streak data—as the primary evidence. Commit volume is a measure of activity, not significance. A petitioner who makes ten commits per day to a personal utility project has a higher commit count than the principal architect of a production-critical compiler, but the latter has made the original contribution. The petition must identify specific contributions to specific repositories and explain what those contributions accomplish, not summarize the petitioner's overall activity across projects.
Asserting adoption through indirect evidence—claiming that a library is widely used because it appears in dependency graphs for many other repositories—has generated RFEs when not supported by specific documentation of who uses the library and for what purpose. USCIS adjudicators cannot verify dependency graph data independently and have been skeptical of adoption claims not supported by identified adopters or documented production deployments. The petition should name specific organizations that use the software and ideally provide a declaration or published statement from a technical leader at one of those organizations confirming that the software is in active production use.
Relying on contributions to large, mature projects without isolating the petitioner's specific contribution and explaining its importance has also proven insufficient. Being a contributor to a well-known project does not establish original contributions unless the petition identifies what the petitioner specifically designed and why it matters within the project. A single well-documented contribution to a significant subsystem of a major project can be more probative than thousands of minor commits to the same project if the former is explained with specificity and the latter are simply listed in a commit log without interpretive context or explanation of their individual technical significance.
Presenting borderline contributions
When the petitioner's open-source work is clearly significant in technical terms but the adoption record is difficult to quantify—because the software is used in proprietary systems, sensitive infrastructure, or by practitioners who do not publish their usage publicly—the petition can address this gap through expert declarations and alternative adoption documentation. A technical leader at a major technology company who can confirm that the petitioner's library is in use within their infrastructure, even without specifying proprietary details, provides specific and credible adoption evidence. Non-disclosure constraints can be addressed by having the declarant confirm use without identifying commercially sensitive information.
A second approach for borderline cases is to supplement the adoption record with evidence of field recognition independent of usage metrics—conference invitations, keynote presentations, or peer review invitations that specifically reference the petitioner's open-source work as the basis for the invitation. When the field recognizes the petitioner's software contributions through invitations to present or review related work, that recognition is itself evidence of significance even when the deployment record is incomplete. These recognition events should be documented with the invitation itself, the conference program, and any published reference to the petitioner's specific contribution.
For petitioners whose most significant contributions are substantial improvements to an existing tool rather than original creations, the argument must engage with the 'original' component of the criterion. USCIS has accepted arguments that a novel and substantial improvement to a field-critical tool can qualify as an original contribution if the improvement itself solves a problem the prior tool could not address. The petition should document what the tool could not do before the petitioner's work, what the petitioner's contribution enabled, and what specific practitioners now accomplish with the improved tool that they could not accomplish before.
Auditing the open-source contributions file
A pre-filing review of the open-source contributions evidence should start from the regulatory standard and work backward: does the assembled evidence demonstrate that this petitioner made original contributions of major significance in the field? Starting from that question exposes gaps more reliably than starting from what documentation happens to be available. The review should confirm that each of the three evidentiary components is present—technical documentation of the specific contribution, independent adoption evidence, and expert declarations—and that none of the three is doing all the evidentiary work while the others are absent.
The expert declarations deserve specific attention in the audit. Each declaration should be reviewed against the regulatory elements: does it explain the specific contribution? Does it address what made the problem difficult or previously unsolved? Does it confirm that the declarant is independently familiar with the work, not just the petitioner's general reputation? Does it address the significance of the contribution relative to what others in the field have produced? A declaration that passes these tests is credible evidence; one that fails any of them should be revised before submission rather than included as filler.
The final step in the audit is to review the petition brief's characterization of the open-source contributions evidence for accuracy and persuasive structure. The brief should lead with the most concrete and compelling evidence—a named production deployment by a significant organization, a peer-reviewed paper that credits the contribution as enabling its research—and build from there to the expert commentary and technical documentation. A brief that leads with metrics and closes with expert opinions is organized in the wrong order: concrete third-party evidence is more credible than self-reported statistics, and the brief should open with its strongest material.
What we typically gather for this kind of case
| Document | Where to source | Why it matters |
|---|---|---|
| Expert letters | 5–8 independent recognized experts | Quality and independence beat volume |
| Certified translations | ATA-certified translator | Required for any non-English source document |
| Exhibit cover sheets | Drafted by counsel, one per exhibit | Tells the adjudicator what each piece shows |
| Bibliometric reports | Web of Science / Scopus | Quantifies impact for original-contributions criterion |
What we see go wrong, again and again
- 01Sending exhibits without a one-paragraph framing memo explaining what each shows and why it matters.
- 02Relying on volume over specificity — five well-targeted expert letters beat fifteen generic recommendations.
- 03Skipping certified translations or using AI translation for foreign-language source documents.