O-1A Guide
How to Build an O-1A Petition for a Researcher Whose Primary Outputs Are Software, Datasets, and Open-Source Code Rather Than Journal Articles
Researchers who primarily produce software, datasets, and open-source code face a specific challenge under the original contributions criterion: their outputs do not fit the standard peer-reviewed journal article pattern. This guide addresses what constitutes major significance for non-traditional research outputs and how to build a strong evidentiary record.
The original contributions criterion and what it requires for non-traditional research outputs
The original contributions of major significance criterion at 8 C.F.R. § 214.2(o)(1)(ii)(A)(5) is the most consequential of the eight O-1A criteria for researchers who primarily produce software, datasets, and open-source code rather than peer-reviewed journal publications. The criterion requires evidence of the beneficiary's original contributions of major significance in the field, and the regulation does not specify the form those contributions must take. Software, datasets, and code are recognized as legitimate scientific contributions by major research-funding agencies, academic institutions, and peer-reviewed journals. The fundamental question for the petition is not whether software and data are eligible evidence forms but whether the specific contributions the beneficiary has made are of major significance within the relevant scientific or technical field.
The O-1A regulatory criteria were drafted before many modern research output types existed in their current form, and the USCIS Policy Manual explicitly acknowledges that petitioners may submit comparable evidence where the standard evidentiary forms do not translate to the beneficiary's field. For software researchers, this means that the petition has a regulatory basis for substituting adoption metrics, citation records of papers that describe or use the software, and evidence of community impact for the journal article citation patterns that the original contributions criterion most naturally accommodates. The petition's cover letter should invoke this framework explicitly and explain why software, datasets, and code are the primary recognized contribution formats in the beneficiary's specific area of research.
Framing the petition correctly requires a precise characterization of the beneficiary's field and the contribution norms within it. A researcher in computational genomics, deep learning infrastructure, scientific computing, or data science works in a field where software and datasets are the primary means by which scientific results are communicated, reproduced, and built upon. The petition should establish this field norm through a brief description of how the field operates — citing the policies of major conferences such as NeurIPS, ICML, or ACL that require code and data submission as a condition of publication, and noting that major funding agencies including NIH and NSF now require data and software sharing plans as components of grant applications — to establish that the beneficiary's contribution format is standard practice, not a peripheral activity.
What counts as major significance for software and data contributions
Major significance for software and data contributions is most directly demonstrated through adoption evidence — the degree to which other researchers and practitioners depend on the beneficiary's contribution for their own scientific work. A software library with a large and diverse user base across academic institutions, government research laboratories, and commercial organizations demonstrates major significance through the breadth of scientific and technical work that depends on it. The petition should document the user base through download records from package repositories such as PyPI, conda, or CRAN, GitHub repository metrics including stars, forks, and contributor records, and letters from research groups at recognized institutions that describe their specific dependence on the beneficiary's software for ongoing research programs.
Academic citation metrics provide a complementary and independently verifiable form of major significance evidence for software and dataset contributions. Many software-primary contributions are described in peer-reviewed papers — methods papers, system papers, or dataset papers published in journals or conference proceedings — and the citation records for these papers can be extracted from Google Scholar, Web of Science, or Semantic Scholar citation databases. A methods paper or dataset paper cited hundreds or thousands of times across peer-reviewed research from multiple disciplines demonstrates that the contribution has had major significance in the scientific community in a way that adjudicators can verify without specialized technical expertise. The petition should document citation records by journal category to show the breadth of impact across disciplines.
Infrastructure contributions — software tools that other widely-used tools are built upon, datasets that define benchmark evaluation standards for a research community, or frameworks that enable an entire category of research that was not previously feasible — provide the strongest form of major significance evidence for software researchers. If the beneficiary's contribution is foundational to the work of a recognized research community, the petition should document this infrastructure role explicitly: which downstream tools depend on the beneficiary's code, which research programs use the beneficiary's dataset as their primary evaluation benchmark, and which scientific publications acknowledge that their results were made possible by the beneficiary's contribution. Dependency documentation is more persuasive than aggregate download counts alone.
Evidence forms that routinely satisfy the criterion for software-primary researchers
Open-source repository metrics provide the baseline documentation layer for software contributions and should be assembled comprehensively before filing. GitHub repository records showing the number of stars, forks, and unique contributors; download histories from package registries such as PyPI, Conda-Forge, or npm; and dependency counts from tools such as Libraries.io or the GitHub dependency graph all provide independently verifiable metrics that adjudicators can confirm. The petition should present these metrics in a comparative context — explaining what download counts, star counts, or dependency counts are typical for widely-adopted research software in the specific field, and where the beneficiary's contribution sits relative to those field norms. Raw numbers without comparison context are difficult for adjudicators to interpret.
Letters from recognized researchers and practitioners who have directly used the beneficiary's software or datasets and who can speak to the significance of the contribution for their specific work provide the most persuasive form of original contributions evidence. These letters should not be generic character references but should describe specifically: what the letter writer's research or technical program requires, how the beneficiary's contribution enables or significantly facilitates that work, what alternatives would exist if the contribution were unavailable, and whether the letter writer regards it as significant relative to other research tools and datasets in the field. Letters from researchers at major universities, national laboratories, or technology research organizations carry the most weight in establishing field-wide recognition.
Funding agency recognition of software and data contributions provides an additional evidence layer that is particularly persuasive for an adjudicator who cannot assess the technical merit of the work directly. NSF's Software Infrastructure for Sustained Innovation program, NIH's Research Software Engineer designation, DOE's Exascale Computing Project, and equivalent programs at DARPA, IARPA, and NASA all fund software contributions to scientific infrastructure based on competitive peer review of the scientific significance and community impact of the proposed work. An award from one of these programs to the beneficiary as principal investigator for the development or maintenance of a research software contribution constitutes direct agency validation of the contribution's significance as a scientific infrastructure investment.
Evidence that USCIS typically discounts for non-traditional outputs
USCIS has consistently scrutinized software contributions that cannot be distinguished from ordinary engineering work. Code that is a standard implementation of an existing algorithm, a routine software tool for internal use by a single organization, or a commercial product without demonstrated research impact does not satisfy the major significance requirement regardless of its technical quality or commercial success. The petition must establish that the contribution is original — introducing a new algorithm, method, system architecture, or dataset that did not previously exist in accessible form — and that it is significant in a way that is recognizable to the relevant scientific community, not merely useful to the organization that commissioned its development.
USCIS has also questioned software contributions where the evidence of adoption is difficult to verify or where the claimed user base cannot be independently confirmed. Download statistics that are self-reported by the petitioner without underlying data from package registries or distribution platforms are easily dismissed. User bases that consist primarily of employees within the beneficiary's own organization rather than independent researchers and practitioners at external institutions provide weaker evidence of field-wide recognition than a diverse user community spanning multiple independent organizations. The petition should document adoption with primary source records from package registries, GitHub, or equivalent platforms, and should emphasize adoption by researchers and organizations that are independent from the beneficiary's employer or institution.
Evidence of commercial success or revenue generation from software does not, on its own, satisfy the original contributions criterion. A software tool with significant commercial revenue demonstrates commercial value but may lack scientific significance — and USCIS evaluates original contributions of major significance within the scientific or technical field, not in the commercial marketplace. Commercial success evidence is relevant to the high salary criterion if the revenue generates high compensation for the beneficiary, but it does not substitute for evidence of scientific significance and field recognition. The petition should carefully distinguish which evidentiary claims address which regulatory criteria and avoid conflating commercial and scientific significance in the original contributions argument.
How to frame borderline evidence from open-source and data contributions
Borderline evidence from open-source contributions requires contextual framing that explains the significance of the contribution to an adjudicator without specialized technical knowledge. A software library with a particular number of GitHub stars is not inherently strong or weak evidence — the significance of that metric depends entirely on what is typical for widely-adopted research software in the specific field. The petition should provide field-specific context by identifying comparable widely-adopted research software projects in the same area, documenting their adoption metrics, and showing where the beneficiary's contribution stands relative to those reference points. This benchmarking approach allows adjudicators to evaluate the relative standing of the contribution within the field without forming independent judgments about technical significance.
Dataset contributions present a specific framing challenge because their adoption is often less visible in standard citation metrics than software tool adoption. A dataset that has become a benchmark evaluation standard for a research community may have thousands of groups using it for research evaluation while the original dataset paper accumulates citations at a slower rate than papers describing new algorithms — because researchers cite the benchmark dataset in methods sections that automated citation indexing tools sometimes miss. The petition should supplement citation records with letters from conference program chairs or benchmark competition organizers who can confirm that the dataset is the standard evaluation instrument for the field, providing context that the citation record alone may not fully capture.
Contributions developed collaboratively with other researchers require careful attribution evidence establishing the beneficiary's specific role within the joint effort. A software project developed by a team of researchers, where the beneficiary designed the core architecture and led the development effort, is a strong original contributions candidate when properly documented — but a petition that presents team-developed software without establishing the beneficiary's specific technical leadership role within the project will leave adjudicators uncertain about the extent of the individual original contribution. Letters from co-developers describing the beneficiary's specific technical contributions, architectural decisions, and leadership of the project provide the attribution evidence needed to tie the joint contribution to the individual extraordinary ability standard.
Assembling and auditing the original contributions file
The pre-filing document inventory for a software-primary researcher should catalog all available evidence forms: software repository metrics from GitHub, package registries, and dependency trackers; peer-reviewed papers describing the contribution and their citation records; letters from independent users at recognized institutions; grant award records from agencies that funded the development; news and technical press coverage; and any formal awards or recognition the software or dataset has received from professional organizations, academic institutions, or research conferences. Each item should be mapped to the original contributions criterion specifically, with a clear explanation of what the document demonstrates about the significance of the contribution to the field. Evidence that does not map clearly to a criterion should be evaluated for inclusion rather than added reflexively.
An expert letter from a recognized researcher in the relevant field who can independently assess the contribution's significance is the most important single document in the file. The expert should be someone who has direct technical knowledge of the relevant software ecosystem or research area, who is not in a conflict-of-interest position relative to the beneficiary, and who can explain in accessible language why the contribution is recognized as significant within the specific research community. The letter should describe what problem the contribution addresses, how the field previously approached that problem, what the beneficiary's contribution changed, and why researchers in the field recognize the contribution as representing an advance of major significance. Technical accuracy is essential — adjudicators may seek informal technical opinions if the letter raises more questions than it answers.
The timing of the petition should account for the trajectory of the software or dataset's adoption. A contribution that was released recently and has not yet accumulated substantial citation records or diverse adoption may benefit from a delay to allow the adoption evidence to mature before filing. Conversely, a contribution with a strong and growing adoption record and multiple expert letters confirming its significance can be filed immediately without waiting for additional evidence. The petition strategy should maximize the strength of the original contributions file because it is the primary criterion for software-primary researchers, and evidence that is thin at filing is difficult to supplement through requests for additional evidence after a petition is denied.
What we typically gather for this kind of case
| Document | Where to source | Why it matters |
|---|---|---|
| Peer-reviewed publications | Web of Science / Scopus exports | Anchors original-contributions and authorship criteria |
| Citation analysis | Google Scholar profile + ESI top-1% data | Quantifies major significance in the field |
| Salary benchmark | BLS OEWS for SOC code + locality | Documents high-salary criterion at 90th-percentile or above |
| Critical-role letters | Direct supervisor + program director | Establishes role's importance, not just title |
What we see go wrong, again and again
- 01Treating extraordinary ability as a credentials checklist rather than a story of field-wide impact.
- 02Submitting bibliometric data (h-index, citation counts) without explaining what makes those numbers high relative to peers in the same sub-field.
- 03Relying on letters from collaborators or co-authors rather than independent experts who can speak to influence.
See if you qualify
Lando reviews your background against the O-1A visa criteria and tells you honestly where you stand. Free, no commitment.