Evidence Building
How to Document GitHub Repository Stars and Download Metrics as O-1A Original Contributions Evidence
Open-source software developers and researchers increasingly use GitHub metrics to support O-1A original contributions arguments. This guide explains how to contextualize stars, downloads, and dependency counts, what USCIS discounts, and how to combine software metrics with expert declarations and citations.
Software metrics and the O-1A petition
Open-source software contributions increasingly define the research impact of computer scientists, data scientists, bioinformaticians, and engineers across multiple disciplines. Researchers who develop widely adopted tools — machine learning libraries, genomics pipelines, data processing frameworks — often find that the most compelling evidence of their contribution's significance is not a citation count but a deployment count: the number of researchers, developers, and organizations who have integrated the petitioner's tool into their own work. GitHub repository stars, package download counts, and dependent repository counts are the native metrics of this form of contribution, and they are increasingly appearing in O-1A petitions as evidence of original contribution of major significance under 8 C.F.R. § 214.2(o)(3)(iii)(E).
USCIS adjudicators are not uniformly familiar with software metrics, which means the petition bears a heavier interpretive burden than it would for traditional citation-based evidence. A paper with 500 citations in a major journal is recognizable to a generalist adjudicator as significant; a GitHub repository with 50,000 stars may not be, unless the petition explains what those stars mean within the developer community, what the distribution of stars looks like across comparable tools, and what the stars indicate about adoption as distinct from curiosity. The petitioner's attorneys should approach software metric evidence as requiring the same level of interpretive scaffolding that citation counts in a specialized subfield require: the number alone does not speak for itself.
The O-1A original contributions criterion requires evidence of original scientific, scholarly, or business-related contributions of major significance. Software tools fall within this criterion when the petition can demonstrate that the tool's adoption has advanced the work of other researchers or practitioners in the field — that the contribution is not just original but significant in its impact on what others are able to do. Metrics from GitHub, PyPI, CRAN, npm, or similar repositories can document that adoption, provided the petition explains the relationship between the metric and the real-world use of the tool and contextualizes the numbers relative to the field's norms.
What the original contributions criterion requires
The regulatory criterion requires two elements: originality and major significance. Originality is typically straightforward for software tools — the petitioner either developed the tool or made substantial original contributions to it. Major significance is where the evidence must do its primary work. USCIS has interpreted major significance to require showing that the contribution has had a notable impact on the field, not merely that it was novel. A tool that is novel but adopted by only a handful of research groups demonstrates originality without major significance; a tool adopted across hundreds of research groups, integrated into widely used workflows, and cited in peer-reviewed publications demonstrates both elements and supports a stronger petition.
The Policy Manual guidance on original contributions recognizes that not all significant contributions take the form of peer-reviewed publications. Software, datasets, and methodological tools developed by researchers can constitute original contributions of major significance when they have been widely adopted, when their adoption has been recognized through citations or published commentary, and when expert declarants can explain the role the tool plays in enabling research that would otherwise be more difficult or impossible. The petition must connect the adoption metrics to the practical impact of adoption — not simply asserting that many people use the tool, but explaining what the tool enables its users to do and why that capability represents a significant advance in the field.
For software tools developed in academic research contexts, citation evidence often complements adoption metrics. When a research tool has been cited in peer-reviewed publications that used the tool in their analyses, those citations document that other researchers independently found the tool useful for scientific work. A petitioner whose tool is cited in a hundred published papers — even in a specialized subfield — can argue that the original contributions criterion is satisfied by the combination of citation evidence and adoption metrics: the citations document recognized use in the research literature, and the adoption metrics document deployment at scale beyond what the citation record alone captures. Both forms of evidence together are typically more persuasive than either alone.
Metrics that typically satisfy the criterion
GitHub repository stars in the range of thousands or tens of thousands, combined with contextual evidence of how the repository is used, are frequently persuasive as original contributions evidence when the petition provides interpretive context. The petition should establish: how many total repositories exist in the relevant technical area, what the distribution of stars looks like across those repositories, and where the petitioner's repository falls in that distribution. A tool that ranks in the top one to five percent of repositories by stars within its technical domain presents a clearer case for significance than a tool with a large absolute star count that nonetheless falls at the median of its peer group. The comparison group must be defined precisely and the comparison evidence submitted alongside the repository metrics.
Download metrics from PyPI, CRAN, npm, Conda Forge, or other package repositories document active installation rather than passive bookmarking. A tool downloaded millions of times from PyPI and listed as a dependency in thousands of other packages demonstrates that the tool has been integrated into active workflows — developers and researchers who installed and integrated the tool into their own software treated it as useful enough to build on. The petition should present download trends over time, the list of dependent repositories or packages if available from the repository's dependency graph, and any industry or research surveys that identify the tool as widely used in its domain. Dependency counts are often more persuasive than download counts because they reflect deliberate integration rather than evaluation.
Published recognition of the software tool provides corroborating evidence that adoption metrics alone cannot fully capture. When the tool has been cited in Nature, Science, Cell, high-impact domain-specific journals, or major conference proceedings at NeurIPS, ICML, ICLR, ACL, or similar venues, those citations document field-level recognition by researchers whose work appears in recognized outlets. The petition should also collect any published benchmarking studies, comparative analyses, or review articles that mention the tool, and any industry adoption examples — major technology companies, government agencies, or research institutions that have used the tool in documented contexts. Published recognition grounds the adoption story in evidence that USCIS adjudicators find familiar as a proxy for significance.
Metrics USCIS regularly discounts
GitHub stars that are primarily the result of marketing activity, social media promotion, or inclusion in aggregate collection repositories rather than organic adoption of a working tool do not effectively support the original contributions argument. Some repositories accumulate large star counts by appearing in popular curated directories without the underlying tool being widely deployed or used. The petition should address this directly if the repository appears in high-traffic collection lists, by providing evidence of actual deployment: download counts, dependency data, user testimonials, or citations that demonstrate active use rather than passive bookmarking. Adjudicators who are aware of this pattern may raise it in an RFE; addressing it proactively strengthens the petition.
Raw download counts without context can be misleading and are frequently discounted when submitted without interpretive scaffolding. A tool with a million PyPI downloads that is primarily used for testing or evaluation, that lacks a stable release history, or that was superseded by a newer tool shortly after release does not demonstrate sustained adoption of a significant contribution. The petition must be specific about the version history, the user base, and the pattern of use: how many distinct users are documented, what kinds of institutions and research groups have used the tool, and whether the tool is in active maintenance and development or has been archived. A tool that was downloaded frequently but is no longer maintained may reflect a historical contribution rather than a currently significant one.
Stars and downloads from geographic regions where the tool is used primarily for educational purposes — tutorials, coursework, student exercises — may indicate broad reach without demonstrating professional-level adoption in research or industry contexts. The petition should segment the evidence by use context where data is available: users from research institutions, industry engineering organizations, or professional development contexts carry more weight for the original contributions argument than users from educational contexts. If segmentation data is available from the repository's analytics or user surveys, it should be submitted and explained. Professional adoption more directly demonstrates that the tool has advanced the state of the art within the field.
Framing borderline software metrics
For petitioners whose software metrics are solid but not clearly top-tier — repositories with several thousand stars, packages with hundreds of thousands of downloads — the argument rests on combining metrics with qualitative context to reach the major significance standard. The petition should focus on specific instances of high-value adoption: the research group at a prominent institution that integrated the tool into their production pipeline, the government agency that used the tool for a documented analysis, the publication in a high-impact journal that credits the tool as the computational platform for the findings. Individual high-quality adoption examples can establish major significance even when aggregate metrics are moderate, because they demonstrate that recognized actors in the field found the work valuable.
Expert declarations from researchers who have used the petitioner's tool in their own work are particularly persuasive for borderline software contributions. A declaration from an established researcher who describes how the tool solved a problem that was not otherwise addressable with existing methods, what findings the researcher was able to produce using the tool, and how the tool has been integrated into the researcher's ongoing work, provides the kind of concrete impact narrative that adoption metrics alone cannot convey. These declarations should be written in specific terms — naming the paper in which the tool was used and describing the specific analytical challenge the tool addressed — rather than in general terms of appreciation.
When the software contribution is part of a larger research program rather than a standalone tool, the petition can present the software contribution as integral to the original contribution rather than as a separate evidentiary category. If the petitioner developed a novel computational method that was implemented as an open-source tool, and the method has been adopted both through citations to the underlying paper and through downloads of the implementation, the petition can argue that the tool and the paper together constitute a single original contribution of major significance. Metrics from each source corroborate the impact of the other, and this integrated framing is often more persuasive than treating the software metrics as an independent criterion argument.
Building and auditing the software evidence file
The software evidence file for an O-1A petition should include: a description of the tool and its technical function, documentation of the petitioner's authorship or primary contribution role, the repository's GitHub page with star count and fork count captured at a specific date with explanation of what those metrics indicate, PyPI or CRAN download statistics with date range and comparison to the tool's peer group, a list of dependent repositories or packages if available, citations to peer-reviewed publications that used the tool, and any published recognition in the form of benchmark studies, review articles, or industry adoption documentation. Each component should be accompanied by explanatory text connecting the metric to the major significance claim.
An audit of the software evidence file before submission should verify that the comparison context is complete. The most common gap is presenting metrics without the peer group comparison that makes them meaningful. If the petition submits a PyPI download count without explaining how it compares to similar tools in the same domain, the adjudicator cannot evaluate significance independently. The petition should establish the comparison group clearly — the set of tools that perform similar functions and are directed at the same user population — and document the petitioner's tool's ranking within that group using data from the same time period and source. GitHub's repository search, Libraries.io's dependency data, and PyPI's own statistics API can provide this comparison data.
Expert declarations for the software contribution should be calibrated to address the specific metrics presented. A declaration that says a tool is widely used and represents a major contribution adds less than a declaration that names the specific research groups who use the tool, identifies the publications in which it was used, and explains how the tool solved a problem that was not otherwise addressable with existing methods. The latter declaration provides specific, verifiable claims that connect the metrics to a concrete impact narrative. When declarations and metrics reinforce each other with specificity, the original contributions argument is more difficult for an adjudicator to dismiss without explicitly addressing each component of the evidence.
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.